dbghelp performance

Markus Amsler markus.amsler at oribi.org
Sun May 6 07:44:40 CDT 2007

Eric Pouech wrote:
> Markus Amsler a écrit :
>> 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).
> Hi Markus,
> does the slightly modified version of pool_heap improve your 
> performances (it shouldn't modify the perf for large files(or just a 
> bit), but should reduce memory consumption for small pools (from 1 to 
> 2M depending on your configuration)
> A+
No, performance is exactly the same as pool_heap :( .
I analyzed why your original insert_first version was slower and memory 
hungrier then pool_heap. It turned out pool_realloc is the problem, not 
pool_alloc. First there's a memory leak, if the memory is moved the old 
one is not freed. Second pool_realloc is O(n) that's the reason for the 
speed hits. Directly using heap functions for reallocs solves both 
problems (but looks to hackish to get commited, perhaps you have a 
better idea).

Here the results for pool_realloc on top of insert_first
pool_realloc            4.5s        54M
pool_realloc,r300    17s        104M     

The next problem is vector_iter_[up|down], because vector_position is 
O(n). Explicitly storing the current iter position speeds r300 up to 8s 
(from original 115s)! But I'm not sure how to implement it cleanly. 
Directly use for() instead of vector_iter_*(), use an iterator, ...

-------------- next part --------------
A non-text attachment was scrubbed...
Name: insert_first.patch
Type: text/x-diff
Size: 1312 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070506/62389cd5/insert_first.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pool_realloc.diff
Type: text/x-diff
Size: 3643 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20070506/62389cd5/pool_realloc.bin

More information about the wine-devel mailing list