Re: Is your Perl running as fast as possible?

[Courage]

in reply to Is your Perl running as fast as possible?

among things discussed on p5p, I remember it was mentioned that some RedHat distributions go with DEBUG-enabled builds of perl, which is rather sad.

In order to get faster build, I tend to turn OFF threading support, which is bad in Perl anyways, and, secondly, I tend to use Perl's memory allocator, which, in turn, is quite a helper and is seemingly better than Tcl's allocator (so when I manage for both Perl and Tcl to use Perl's memory allocator, I see some additional speedup)

As for dramatic speed improvements, related to your XML parsing, it is quite possible for Perl to use or not use Pure-perl and XS parts of module, so check whether your slower installation lacks some binary module.
You may even copy perl between different OSes and see if this result in differences

As a final note, Tcl::Tk is twice faster compared to Perl/Tk

[Anonymous Monk]

among things discussed on p5p, I remember it was mentioned that some RedHat distributions go with DEBUG-enabled builds of perl, which is rather sad.

What's bad about running a debug enabled perl? Are you worried about a microscopic increase in the size of the perl binary caused by debugging symbols? Is there something else I should be aware of?

[perrin]

It's a little slower. Compiling for threads make it a lot slower.

[Courage]

not only "debug symbols" that binary will contain, it will also contain code within some #ifdef's; yet some -Oxxx are disabled

Let's RTFS a bit -- following is an excerpt from ./win32/makefile.mk (same for linux build, I guess)

#
# uncomment next line if you want debug version of perl (big,slow)
# If not enabled, we automatically try to use maximum optimization
# with all compilers that are known to have a working optimizer.
#
#CFG        *= Debug