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." > (http://lists.freebsd.org/pipermail/freebsd-hackers/2003-September/003059.html) > > 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 > investigated.... 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. Bye, Alexander. -- I will be available to get hired in April 2004. http://www.Leidinger.net Alexander _at_ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7Received on Tue Jan 06 2004 - 07:19:33 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:36 UTC