Bill Dorsey wrote:

> Thor Simon wrote:
>
>> 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.

At the risk of going off on a tangent...

I would contend that operating systems and applications each form part
of the system as a whole, and share reponsibility for the performance of
the system.  At times no OS/library/whatever can compensate for flaws in
applications (and vice versa, of course).

> Furthermore, one measure of their value is in their ability to
> service software that places difficult demands on the services
> provided.

Granted, but within limits.


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

Everything is relative.

The judgement that "everyone has at least 64 MB, and that is a lot of
memory" would be a dangerous one.  Sure generalisations need to be made
at times, but if we have several algorithms available with different
performance profiles/trade-offs (e.g. in terms of speed and space) then
I would favour allowing the programmer to choose the algorithm if they
deem it appropriate.

The phrase "embedded application" springs to mind as one example where
libraries should be able to have trade-offs tuned...
In some application cases I've seen even 256 MB doesn't leave much free
space (these guys were dealing with LARGE data sets) and memory
footprint becomes an important issue again.
I'm sure we can all find examples to support many different trade-offs.


> It is my contention that in general, the operating system should
> trade memory for speed within some reasonable bounds.

As long as we keep the words "in general" in mind...
__
David Burren