perl malloc slow?
Alexander at Leidinger.net
Tue Jan 6 08:19:33 PST 2004
On Tue, 06 Jan 2004 15:36:34 +0000
Holger Kipp <Holger.Kipp at alogis.com> wrote:
> Kris Kennaway wrote: "For any algorithm one can come up with a workload that
> makes it perform badly. The trick is making it perform well for
> common workloads, which FreeBSD's malloc does."
> Even so, if Perl malloc and Linux malloc are O(n) with a small constant and
> FreeBSD malloc behaves like O(n*n) or worse with a large constant in this
> easy example (of a real-world applikation), this behaviour should imho be
You need to make a context switch for every malloc call. AFAIK perls
malloc has a resource pool, from which it allocates if possible. This
saves a context switch for each malloc call which can be satisfied from
the resource pool. If the Zlib module allocates alot of small memory
regions with the same size one after another and frees alot of them
after a short period of time, this results in a huge amount of context
switches in the non-perl-malloc case and in nearly no context switch in
the with-perl-malloc case.
The right thing to do in such a case is to optimize the application to
use e.g. a ring buffer. A static number of malloc() calls at startup,
use them for a long time, free() them. Or to manage a malloc resource
pool on it's own. This is what perl does in the with-perl-malloc case.
AFAIK perl uses its own malloc on GNU/Linux... feel free to correct me
(perl -V | grep usemymalloc).
I tried to convince our perl maintainer to use perls malloc (5.6.1
doesn't use it by default) long ago, but I failed (but I got the
WITH_PERL_MALLOC switch in the port).
Somewhat (un)related: use perl malloc if you encounter problems in a
perl application which uses signals.
I will be available to get hired in April 2004.
http://www.Leidinger.net Alexander @ Leidinger.net
GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7
More information about the freebsd-current