in reply to Re^2: undef quite slow?
in thread undef quite slow?

And I am not entirely sure what you mean by "with or without perl's malloc" - could you elaborate a bit on the pros and cons of that?
Perl is usually (by default?) compiled with your libc's malloc. Perl can also be compiled to use its own malloc ( perl -V:usemymalloc ). My suggestion is advice from perlfaq3, particularly from "How can I make my Perl program take less memory?". I really don't know much about it (never use it), but perl's malloc is supposed to be faster (or better suited for perl), but may present a challenge when compiling some eXStension (at least as-hinted-by http://inline.perl.org/java/faq.html). You can find more reading if you grep perl/lib/Pod/ for malloc
I don't think I can upgrade the libc on this machine.... I've just tried it on a very differently configured machine (perl -V output for that one is below) and it doesn't seem to have the same problem, unfortunately the above configuration is what we use everywhere.
You'll notice that that the "working" perl is compiled with libc=/lib/libc-2.3.2.so, while the one you use everywhere is compiled with libc=/lib/libc-2.2.5.so. You should be able to compile perl with a newer libc without replacing/upgrading your systems current libc.

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
** The third rule of perl club is a statement of fact: pod is sexy.