Markus Amsler a écrit :
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 :( .
even for memory consumption ???
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).
we could try not to realloc the array of arrays but rather use a tree of
arrays which should solve most of the issues, but that would make the
code complicated
another way is to double the size of the bucket each time we need to
increase size (instead of adding one bucket)
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, ...
likely use an interator which keeps track of current position (as we do
for the hash tables)
A+
--
Eric Pouech
"The problem with designing something completely foolproof is to underestimate the
ingenuity of a complete idiot." (Douglas Adams)
