dbghelp performance
Eric Pouech
eric.pouech at wanadoo.fr
Wed May 2 14:48:16 CDT 2007
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)
More information about the wine-devel
mailing list