In message <[EMAIL PROTECTED]>, 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
[EMAIL PROTECTED] | 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
