Date: Thu, 14 Mar 2002 07:04:06 +0100 From: Poul-Henning Kamp <phk@critter.freebsd.dk> To: John Indra <maverick@office.naver.co.id> Cc: freebsd-current@FreeBSD.ORG Subject: Re: malloc() and the stock Perl in -CURRENT (and -STABLE) Message-ID: <40628.1016085846@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 14 Mar 2002 10:45:25 %2B0700." <20020314104525.B8244@office.naver.co.id>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20020314104525.B8244@office.naver.co.id>, John Indra writes: >Dear all... > >This morning I found a very interesting mail. All of you can see it from: > >http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1669241+0+current/freebsd-questions > >As stated in the mail, a simple Perl script like this: > >-- Begin -- > >#!/usr/bin/perl > >$temp = ""; >$begin = time; >for ($i = 0; $i < 1000000; $i++) { > $result .= "$i\n"; >} >print "Exec time: ", time - $begin, " secs\n"; > >-- End -- > >can show that there PROBABLY is something wrong with malloc() in -CURRENT >and -STABLE. No, there is nothing wrong as such, it is a deliberate design-choice in phkmalloc() which conflicts with perls use of realloc(). Basically I profiled a lot of programs and found that very few programs used realloc() and decided that consequently it was the least important of the entries from a performance point of view. The above perl program results in a loop more or less like: n = 2 for (i = 0; i < 1000000; i++) realloc(n++); Now, if you read _any_ malloc(3) man page, they will tell you that there is no way it can be guaranteed that this does not result in a lot of copying. (insert bikeshed discussion about wisdom of the above code, assume I maintain the opinion throughout that it is braindamaged to be that stupid in a so central program as perl) At the cost of considerable complexity (a mremap(2) implementation amongst other things), realloc in phkmalloc(3) can be optimised but it is not on my plate right now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40628.1016085846>