dbghelp performance

[Markus Amsler]

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