On Tue, 22 Feb 2005 12:52:33 +0100, Anders Rønningen wrote:
We have done some profiling using oprofile, and found that most of this time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll module. The time needed to locate a free heap block increases gradually, from a few iterations up to about 15000 in the project we are building. We suspect that this may be due to fragmentation caused by the heap allocate/free algorithms.
That is quite possible. You can get a dump of the heap by doing a +heap trace, so there must be a function somewhere that generates it. Just trigger that when HeapFree gets too slow and see what it looks like.
You might (*might*) be able to get a feel for this by hacking the code to use glibcs malloc/free instead of our own heap implementation (but only when accessing the process heap). I do not know what might break if you do that. Doug Leas malloc may or may not be higher performance than ours.
thanks -mike