From owner-freebsd-current@FreeBSD.ORG Tue Jan 6 07:36:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8205F16A4CE; Tue, 6 Jan 2004 07:36:58 -0800 (PST) Received: from alogis.com (firewall.solit-ag.de [212.184.102.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3159543D1F; Tue, 6 Jan 2004 07:36:56 -0800 (PST) (envelope-from Holger.Kipp@alogis.com) Received: from intserv.int1.b.intern (localhost [127.0.0.1]) by alogis.com (8.11.1/8.9.3) with SMTP id i06FadY90540; Tue, 6 Jan 2004 16:36:39 +0100 (CET) (envelope-from hk@alogis.com) Message-Id: <200401061536.i06FadY90540@alogis.com> Date: Tue, 06 Jan 2004 15:36:34 +0000 From: Holger Kipp To: Alexander@Leidinger.net X-Mailer: phpGroupWare (http://www.phpgroupware.org) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-description: Mail message body cc: stable@freebsd.org cc: current@freebsd.org Subject: Re: perl malloc slow? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Holger.Kipp@alogis.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2004 15:36:58 -0000 Alexander Leidinger (Alexander@Leidinger.net) wrote: > >On Tue, 06 Jan 2004 11:29:05 +0000 >Holger Kipp wrote: > >> Searching on the internet gave the impression that this might be >> malloc/FreeBSD related. Any chance of this being resolved? > >Use perls own malloc implementation (make -DWITHOUT_PERL_MALLOC for an >up-to-date perl5.8 port, if you use make -DWITH_THREADS perls own malloc >implementation gets disabled by the FreeBSD port)? AFAIK perl 5.0 in the >4.x basesystem doesn't use its own malloc implementation. Upgraded Perl 5.8.0 to 5.8.2 which has these switches set already, so I guess the problem is well-known. 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.... See also http://www.dent.med.uni-muenchen.de/~wmglo/malloc-slides.html Regards, Holger