[quagga-dev 3160] Re: [PATCH] lib/buffer.c: keep one buffer_data to avoid malloc/free thrashing

Paul Jakma paul at clubi.ie
Tue Apr 12 00:19:12 BST 2005

On Mon, 11 Apr 2005, Andrew J. Schorr wrote:

> I don't think so.  I did that analysis on Solaris 8; is libumem 
> available on Solaris 8?

Doesnt appear to be the case (which means i should adjust 

> It just so happens that I have quantify only on solaris 8/sparc, 
> and that's the easiest tool for me to use for performance analysis.


What is this quantify thing? Should I have heard of it?

> I guess the right thing to do would be to profile it on linux, but 
> I'm pretty convinced in any case that it's a win to cache a buffer 
> and avoid malloc/free churn.  It seems impossible to me for there 
> to be a malloc library that is fast enough to make caching a buffer 
> a bad idea.

You might be surprised though. Libumem (which provides essentially 
the de-facto performance orientated malloc on Solaris) and glibc 
should be pretty good.

Libumem will definitely be a /lot/ better than the stock S8 malloc. 
But you need s9 4/03 I think:


> What's the real downside of holding onto a one-page buffer?

It just seems wrong :). Do it for one 'special case', do it for 
another, and so on. Where do you end up? With every little corner of 
code preciously clutching a page or two of memory?

Most of all, you would be subverting a /good/ malloc. You're taking 
pages forever. Pages which could prevent an implementation from 
shrinking the heap a little, or whatever..

It just seems wrong in general, even if i can see that for each 
instance it will undoubtedly be faster than going into a malloc 
implementation (even a really good one).

> Regards,
> Andy

Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
"Oh my!  An `inflammatory attitude' in alt.flame?  Never heard of such
a thing..."
-- Allen Gwinn, allen at sulaco.Sigma.COM

More information about the Quagga-dev mailing list