NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/unix/programm/4443

Internet Message Format | 1992-08-25 | 1.6 KB

Path: sparky!uunet!nwnexus!ole!rwing!fnx!sgihbtn!markmc
From: [e-mail] (Mark McWiggins)
Newsgroups: comp.unix.programmer,comp.sys.hp.comp.sys.dec
Subject: Best malloc(3) replacement for huge sys w/many small objects?
Summary: slow
Message-ID: <[e-mail]>
Date: 24 Aug 92 23:46:44 GMT
Sender: [e-mail]
Organization: Sierra Geophysics Inc.,  Kirkland, Wa
Lines: 25
Nntp-Posting-Host: grumpy

We're building a large application that seems to have reached a threshold
in the use of dynamic memory. A routine that allocates 300 or so small
objects was running acceptably fast, but with changes to the program
started to bog down after the first 75 or so allocations.

I believe I've narrowed it down to the malloc() subsystem, but I'm not
positive about this ...

In any event, I'm going to begin my effort to tune the system by changing
out malloc(), because I'll have to find a malloc() replacement for the
Decstation when we port the system there. Its man page contains this helpful
caveat:

     Currently, the allocator is unsuitable for direct use in a large virtual
     environment where many small blocks are kept, since it keeps all allo-
     cated and freed blocks on a circular list.  Just before more memory is
     allocated, all allocated and freed blocks are referenced.

I see several versions of malloc in the UUNET archive, and I believe Knuth
had this problem nailed down. Do you have a recommendation for this situation?

Thanks in advance.
--
Mark McWiggins           [phone]x377 days      Box 31356
[e-mail]        [phone] hrs.       Seattle WA 98103-1356