Memory allocator performance in C/C++ compilers

While writing a parser under Microsoft Visual C++, I compiled the same
source under linux-gcc2 to see how a different RTL and compiler would
perform. Surprisingly, on a large test file gcc beat VC++ by a
significant margin (over 20%.) Somewhat surprised by these results, I
tested both under their respective profilers, and it turned out that
the Visual C++ version was spending a disproportionate amount of time
allocating memory. So, I wrote a fairly simple benchmark to test raw
RTL memory allocation speed.


I tested the benchmark on Watcom 10.6, linux-gcc 2.7.2, and Visual C++
6.0. Watcom and gcc2 were fairly close in speed, but VC++'s allocator
was an order of magnitude worse. I tried changing the allocation size,
the number of blocks being allocated, and the pattern for interlacing
allocation, but all to no avail, as the results were consistent. This
was not a debug build; the code was built using the default Release
settings, and the program was run from the command-line (i.e. the
debugger was not present.)


Am I missing something? Are there other things influencing allocator
performance besides block size, number of blocks, and allocation
pattern? Or is VC++'s memory allocator just slower than the other
compilers? 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
program?


Thanks in advance,
-ed
[I've seen enormous differences in different versions of malloc.
Some have worst case behavior on FIFO or LIFO or close to it,
some are O(N^2) when the free list gets long, some are just plain
buggy. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.