[quagga-dev 3160] Re: [PATCH] lib/buffer.c: keep one buffer_data to avoid malloc/free thrashing
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).
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
-- Allen Gwinn, allen at sulaco.Sigma.COM
More information about the Quagga-dev