My $0.02US on the memory allocator slowdown:

Under Irix 5.?, malloc() and free() maintained a list of memory blocks.
There were some small blocks and some large blocks.  When a malloc() call
was made, a certain number of entries on the free list were checked.  If a
block of the requested size wasn't found in the first N entries, more
memory was sbrk()'d from the OS and life continued on.  

We got into trouble be malloc()'ing and free()'ing hundreds of blocks in a
row.  The original code would request memory for data buffers, write them
to disk, then free them.  What started to happen was the freeing of a large
number of buffers of size A, then the freeing of a large number of buffers
of size B.  The free() call would put all the A size blocks on the free
list, then all the B size blocks.

As Murphy's law predicts, the code would then need a block of size B.
Since the head of the free list was all size A, a sbrk() would be done.
This would continue until this single process owned every block of memory
in the system, yet didn't use it!

Our quick fix was somewhat simple.  Since we knew the maximum number of
blocks we would request, we just bumped the N parameter up.

steven_grunza@ieee.org

At 10:34 PM 12/20/99 +0200, Jukka Marin wrote:
>On Mon, Dec 20, 1999 at 02:42:13PM -0500, Ken Hornstein wrote:
>> >Once upon a time, there was a Finnish guy who whined about Applixware
>> >being real slow on his NetBSD machine.  This guy is back!
>> 
>> This was a while ago .... but didn't we determine that the _root_
>> problem was that Applixware caused the X server to do a whole lot of
>> mallocs and free's, and that eventually caused the memory allocator
>> to take forever?  That's my hazy memory on the subject.
>
>Something like that, yes.  But why does the memory allocator get slower
>and slower?  Isn't this some kind of a bug?
>
>> - Try using an X protocol analyzer to see what Applixware is doing.
>>   Do I have one?  No. Geez, someone should have _written_ one by now.
>>   Does anyone know of such a thing?
>
>I think one problem with Applix is that it uses synchronous requests
>(or whatever they are called ;) to the X server and waits for the
>request to be completed before sending the next request/command.  Why -
>dunno.
>
>> - Profile the X server to figure out what it is doing.
>> - Once you've done one of those things, generate a test program
>>   that reproduces this behavior (not an X program, I think the root
>>   cause is far underneath).
>
>Hmm, I guess I should dig up the old e-mails and see what was discovered
>before..  I was hoping the problem would go away with the new VM system
>and stuff, but it's still there.  Also, someone said that he did NOT have
>the problem, so I thought it was something with my linux libraries.. but
>now I have rebuilt my whole system from scratch and installed the libs
>from pkgsrc and the problem is STILL there, so ..
>
>> I know that in my case, I would like to help you ... but if the only
>> way to reproduce the problem is "run Applix", well, it makes it rather
>> difficult to reproduce it myself.
>
>Maybe I should send you an Applixware CD.. I have purchased three copies
>so far (because updates are unavailable or too expensive here!) :-I
>
>  -jm
>
>