Markus Amsler a écrit :
I've played around with dbghelp performance. My test case was breaking at an unknown symbol (break gaga) while WoW was loaded in the debugger (wine winedbg WoW.exe). The time was hand stopped, memory usage measured with ps -AF and looked at the RSS column.
Test Time(s) Memory Usage(MB) current git 4.5 54 pool_heap.patch 4.5 63 process_heap.patch 4.5 126 insert_first.patch 4.5 54 current git, r300 115 146 pool_heap.patch, r300 17 119 process_heap.patch, r300 17 260 insert_first.patch, r300 27 167
insert_first is the patch from Eric Pouech. r300 means with the debug version of Mesas r300_dri.so, which has a total compilation unit size of around 9.2M (compared to the second biggest Wines user32 with 1.1M).
Conclusions:
- current git wins with small debug files (<2M or so), pool_heap wins
with bigger files. insert_first, process_heap are out.
- small pools have less memory overhead than small heaps
- big pools have more memory overhead than big heaps.
- big pools are a lot slower than big heaps.
thanks for the testings & timings !
you're also missing a couple of elements: - for the memory overhead, in the first case you consider 50 MB (roughly) over 10 or 20 modules while in your r300 case the impact (and memory difference) is only on a single module - time to unload a module hasn't been computed (it's less used than loading a module)
what's also strange is that the pool_heap gets lower memory consumption than the process heap one, which is rather not a natural result... I wonder if some data haven't been swapped out and aren't accounted for in RSS A+