Memory allocator performance in C/C++ compilers

"ed mckenzie" <eem12@cornell.edu>
22 Jan 1999 21:38:23 -0500

          From comp.compilers

Related articles
Memory allocator performance in C/C++ compilers eem12@cornell.edu (ed mckenzie) (1999-01-22)
Re: Memory allocator performance in C/C++ compilers eodell@pobox.com (1999-01-25)
Re: Memory allocator performance in C/C++ compilers chase@world.std.com (David Chase) (1999-01-25)
Re: Memory allocator performance in C/C++ compilers vmakarov@cygnus.com (Vladimir Makarov) (1999-01-25)
Re: Memory allocator performance in C/C++ compilers eem12@cornell.edu (ed mckenzie) (1999-01-27)
Re: Memory allocator performance in C/C++ compilers johnsgreen@worldnet.att.net (John S. Green) (1999-01-27)
Re: Memory,allocator,performance in C/C++ compilers markusk@bidra241.bbn.hp.com (Markus Kohler) (1999-01-27)
[1 later articles]
| List of all articles for this month |
From: "ed mckenzie" <eem12@cornell.edu>
Newsgroups: comp.compilers
Date: 22 Jan 1999 21:38:23 -0500
Organization: cornell university
Keywords: storage, performance

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]



Post a followup to this message

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