Hi,

Thor Simon wrote:
> Um, just *when* was it noted that it was "faster"?  It was never 
> faster; it
> can't have been faster; it will never be as fast; the old malloc 
> was a totally
> mindless powers-of-two allocator, which is about as fast as you can get.
>
I compiled my C++ application with gnumalloc and added the
timing to my earlier table:

libc.so.61      MALLOC_OPTIONS=""       38.229u 61.542s
libc.so.61      MALLOC_OPTIONS="h"      32.475u  0.048s
libc.so.40      MALLOC_OPTIONS=""       29.716u  0.043s 
libgnumalloc.so MALLOC_OPTIONS=""       28.965u  0.047s

Looks like gnumalloc is comparable in performance to the old malloc
and noticeably better than the new one (at least on my 1.4Y
Alpha system).

> On the other hand, it's my point of view that applications which perform
> significantly worse with the current malloc are in many cases 
> poorly designed;
> they should manage their memory allocation themselves to a much greater
> extent rather than calling malloc for 3 bytes all the time.  If 
> you take this
> as a criticism of C++ itself, you'd be pretty much on-target.
> 
Interesting.  I always thought operating systems were designed for
the express purpose of servicing applications programs, regardless
of what language they are written in.  Furthermore, one measure of
their value is in their ability to service software that places
difficult demands on the services provided.

It is my contention that in general, the operating system should
trade memory for speed within some reasonable bounds.  Typical
systems today have 64 megabytes or more so there is no reason to
try to squeeze every last byte out of a memory allocator if it
has a significant speed penalty associated with it.  Obviously,
there are exceptions to this rule if you are running on a
palmtop computer or other similarly handicapped hardware.  I
don't believe it is reasonable to sacrifice performance across
the board for the sake of a handful of machines with limited
memory resources, however.

--
Bill Dorsey