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

"ed mckenzie" <eem12@cornell.edu>
27 Jan 1999 12:12:10 -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: "ed mckenzie" <eem12@cornell.edu>
Newsgroups: comp.compilers
Date: 27 Jan 1999 12:12:10 -0500
Organization: cornell university
References: 99-01-081 99-01-094
Keywords: storage, performance

David Chase wrote...
>Long, long ago, this paper was written comparing various memory
>allocators:


Thanks to all for the useful information. It was pointed out to me by
someone in private e-mail that the multithreaded Microsoft
implementation makes heavy use of Win32 mutexes, which are devastating
to their allocator's performance. He also noted that VC++'s free()
algorithm walks the allocation list, something that in his humble
opinion should never be done in a "decent" allocator.


I also tested Watcom C/C++ 10.6 to see where it stood relative to gcc2
and VC++, and it clocked the best allocation times of all; their
allocator edged linux-gcc and beat VC++ by an order of magnitude. So
it's definitely an RTL issue, and not an OS issue.


Thanks again,
-ed

Post a followup to this message

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