dbghelp performance
Markus Amsler
markus.amsler at oribi.org
Wed May 2 18:44:01 CDT 2007
Eric Pouech wrote:
> 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
I'm not sure what's your point is.
> - time to unload a module hasn't been computed (it's less used than
> loading a module)
Unloading is more or less instant in all cases.
> 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
The process_heap is the one I sent to wine-patches, which never frees
any memory.
I've also tested an improved process_heap, which stores the allocated
memory pointer in an array and frees it afterwards. Without luck, it's
slower and uses more memory the pool_heap.
So I don't see a simple solution which only affects storage.c, is equal
or better than the current, and is significantly faster at big debug
files. Any ideas?
Markus
More information about the wine-devel
mailing list