|Memory allocator performance in C/C++ compilers email@example.com (ed mckenzie) (1999-01-22)|
|Re: Memory,allocator,performance in C/C++ compilers firstname.lastname@example.org (Markus Kohler) (1999-01-27)|
|From:||Markus Kohler <email@example.com>|
|Date:||27 Jan 1999 13:02:06 -0500|
|Organization:||Hewlett Packard GmbH, BSTD R&D|
"ed mckenzie" <firstname.lastname@example.org> writes:
> Am I missing something? Are there other things influencing allocator
> performance besides block size, number of blocks, and allocation
Yes the algorithm used for example. Depending on the algorithm some
allocators are better for small blocks and others are better for
> Or is VC++'s memory allocator just slower than the other >
Since I haven't analyzed yet I can't tell you if it is really slower.
But my experience with allocators on other platforms( HP-UX) shows
that there are significant differences in allocator performance. For
example I found that the HP-UX is rather slow compared to for example
Doug Leas allocator (http://g.oswego.edu/) . As far as I remember it
was a factor of 4 or 5.
> Interestingly, there's a third-party allocator for VC++ (UltraHeap)
> that claims similar performance gains over the standard 6.0 RTL
> allocator. Is there a heap benchmark that could measure this sort of
> thing with more accuracy and completeness than a simple test
I can recommend you Doug Leas allocator it's free and I think it works
on Windows too. The last time I tested gnu-malloc it was slower when
this allocator (at least on my platform HP-UX).
Another thing you should consider is implementing an allocation scheme
yourself for the most important datastructures.
Markus Kohler mailto:email@example.com
Return to the
Search the comp.compilers archives again.