Re: Memory allocator performance in C/C++ compilers

eodell@pobox.com (Eric O'Dell)
25 Jan 1999 21:51:39 -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 rosinowski@gmx.de (1999-01-27)
| List of all articles for this month |

From: eodell@pobox.com (Eric O'Dell)
Newsgroups: comp.compilers
Date: 25 Jan 1999 21:51:39 -0500
Organization: Compilers Central
References: 99-01-081
Keywords: storage, performance

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


>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%.)


This may have less to do with the compiler than with the OS.


I haven't really examined memory allocation performance under a 32-bit
version of Windows, but I recall that under the 3.x series, the native
OS memory management was hideously slow, and some RTLs implemented
malloc as a simple wrapper around an API call, thereby inheriting that
inefficiency. John Walker's bget memory allocation library
(http://fourmilab.ch/bget/), which is (almost) a drop-in replacement
for malloc, produced a significant performance boost. I have no idea
if the same would be true with Win95/98.


-E.


Post a followup to this message

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