NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/lang/cplus/18333

Text File | 1992-12-22 | 2.4 KB | 56 lines

Newsgroups: comp.lang.c++
Path: sparky!uunet!cybvax0!zeev
From: [e-mail] (Zeev Mehler)
Subject: Special-purpose-heap-managers - references, FTP?
Message-ID: <[e-mail]>
Organization: Cybermation, Inc.
Date: Tue, 22 Dec 92 16:58:26 GMT
Lines: 46

> BS says, that use of a special-purpose-heap-manager could speed up a program,
> -that is, a "normal" program, that uses medium-heavy dynamic-allocation,
> I guess(!)-, with a factor 2! Based on a few simple tests, I would not be
> surpriced, if the speed-up could be much, much higher - say, 100x for a not
> too heavily, dynamically allocating program of mine! Is that unrealistic;
> based on an unrealistic, simple test?

> Could anyone, -who have tried-, tell, what kind of experiences they have with
> special-purpose-heap-managers like 'Pool', in what kind of program, with what
> kind of result/speed-up?

>         -- Morten.

Since this is an area that we are currently working in I'll throw in my 2 cents
worth on the subject.

C++ tends to exercise the heap manager very intensively.  Some system vendors
have put in quite a bit of effort to improve their malloc packages to
primarily become space effecient.  Typical programs on these machines
running in memory, spend less than 10 percent of their time in malloc.  Memory
buffering tricks will save max about 5% of run time.

However, if a program is in a situation where paging is unavoidable, which
tends to occur more quickly for systems that have not made their mallocs space
effecient, then the time a program spends in malloc/free can jump dramatically.

In a paging situation, focusing on managing free lists and being able to
reallocate efficiently becomes paramount to a C++ programs performance.

Ideally one wants a system that works very quickly in memory, but also
inherently minimizes paging hits.

In practice we have found that for optimum performance one needs a variety
of allocation strategies that work together.  A strategy that works well for
32 byte allocations is not necessarily optimum for 700 byte allocations.

While it is possible to accomplish this on a class basis, we feel that this
stuff should be hidden from the individual programmer and managed on a system
wide basis.

                       Ze'ev
--
-------------------------------------------------------------------------------
Ze'ev Mehler                Tel: [phone]
NewCode Technology, Inc.        Fax: [phone]
200 Boston Ave.                Email: [e-mail]