[sb.pm] Re: Perl Compiler

James Keenan jkeen at verizon.net
Fri Nov 12 17:55:40 CST 2004


> Date: Thu, 11 Nov 2004 13:40:29 -0500 (EST)
> From: Kostas Pentikousis <kostas at cs.sunysb.edu>
> Subject: [sb.pm] Perl Compiler (fwd)
> To: Andrew Mehler <mehler at cs.sunysb.edu>
> Cc: Stony Brook Perl Mongers <stonybrook-pm at mail.pm.org>
> Message-ID: <Pine.GSO.4.53.0411111336270.9787 at compserv3>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
> Hi Andrew,
>
> It pretty much depends on what exactly you're doing. After a quick
> search I have a couple of links for you:
>
> Optimize Perl
> http://www-106.ibm.com/developerworks/library/l-optperl.html
>

FWIW:

You should note that this article has been subjected to some scorching 
criticisms on comp.lang.perl.misc starting on 10/23/04.  Here, for 
example, is what Uri Guttman (author of one of the other recommended 
articles) wrote:

  "so many misconceptions about perl that i can't even start.  and
         he misses so many ways to optimize perl as well.

         no mention of the Benchmark.pm module.

         perl bytecode is generally useless and doesn't give much speedup

         choosing a better algorithm and/or data structure is the best
         way to optimize code in any language. if you think perl 's speed
         is the problem then you either chose the wrong language or don't
         know how to code perl efficiently. examining bytecode is silly
         in this context. it still won't show you which ops are the
         bottlenecks.

         the speed difference between single and double quoted strings is
         negligible. try a benchmark yourself. double quoted strings are
         converted to a join of the string parts at compile time so there
         is no runtime loss for simple strings."


> When perl is not quite fast enough
> http://www.ccl4.org/~nick/P/Fast_Enough/

Heard that talk.  Recommend it.

Jim Keenan



More information about the StonyBrook-PM mailing list