dbghelp performance

[Eric Pouech]

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+


-- 
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)