On 12/18/06, Zoran Vasiljevic <[EMAIL PROTECTED]> wrote:
On 16.12.2006, at 19:31, Vlad Seryakov wrote:
> But if speed is not important to you, you can supply Tcl without
> zippy,
> then no bloat, system is returned with reasonable speed, at least on
> Linux, ptmalloc is not that bad
OK. I think I've reached the peace of mind with all this
alternate malloc implementations...
This is what I found:
On all plaforms (except the Mac OSX), it really does
not pay to use anything else beside system native
malloc. I mean, you can gain some percent of speed
with hoard/tcmalloc/nedmalloc/zippy and friends, but you
pay this with bloating memory.
Are you saying you tested your app on Linux with native malloc and
experienced no fragmentation/bloating?
I think some people are experiencing fragmentation problems with
ptmalloc -- the Squid and OpenLDAP guys, for example. There's also
the malloc-in-one-thread, free-in-another problem, which if your
threads don't exit is basically a leak.
If it's not a problem for your app then great! Just wondering...
If you can afford it,
then go ahead. I believe, at least from what I've seen
from my tests, that zippy is quite fast and you gain
very little, if at all (speedwise) by replacing it.
You can gain some less memory fragmentation by using
something else, but this is not a thing that would
make me say: Wow!
Exception to that is really Mac OSX. The native Mac OSX
malloc sucks tremendously. The speed increase by zippy
and nedmalloc are so high that you can really see
(without any fancy measurements), how your application
flies! The nedmalloc also bloats less than zippy (normally,
as it clears per-thread cache on thread exit).
Doesn't zippy also clear it's per-thread cache on exit?
Actually, did you experiment with exiting the conn threads after X
requests? Seems to be one of the things AOL is recommending.
One thing I wonder about this is, how do requests average out across
all threads? If you set the conn threads to exit after 10,000
requests, will they all quit at roughly the same time causing an
extreme load on the server? Also, this is only an option for conn
threads. With scheduled proc threads, job threads etc. you get
nothing.
So for the Mac (at least for us) I will stick to nedmalloc.
It is lightingly fast and reasonably conservative with
memory fragmentation.
Conclusion:
Linux/solaris = use system malloc
Mac OSX = use nedmalloc
Ah, yes... windows... this I haven't tested but nedmalloc
author shows some very interesting numbers on his site.
I somehow tend to believe them as some I have seen by
myself when experimenting on unix platforms. So, most
probably the outcome will be:
Windows = use nedmalloc
What this means to all of us:? I would say: very little.
We know that zippy is bloating and now we know that is
reasonably fast and on-pair with most of the other solutions
out there. For people concerned with speed, I believe this
is the right solution. For people concerned with speed AND
memory fragmentation (in that order) the best is to use some
alternative malloc routines. For people concerned with fragmentation
the best is to stay with system malloc; exception: Mac OSX.
There you just need to use something else and nedmalloc is the
only thing that compiles (and works) there, to my knowledge.
I hope I could help somebody with this report.
Cheers
Zoran
