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) |
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.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.