You are lucky, because I am free to work on this for cPanel for the next years :) At cPanel they compile perl for more than 10 years and most of their speedup is with optimizing the perl code, not so the compiler. The problem is that perl, the language, is too dynamic to be optimizable. Too much slowdown (magic, module imports, ...) and changes can happen at run-time. Also the language is not clear enough. The ops contain the needed optimizer info, not the data. So it's dealing with a lot of run-time and side-effects.

If you only need better startup time B::C is already stable and good enough. For optimized run-time more is needed.

I did some research and lobbying over the last years and came up with those approaches:

Did you see my inofficial (not yet announced) proposals on github? I'm working on const and a type system to enable future optimizations. Time-frame: 1-2 years.

perl design draft - types and const

https://github.com/rurban/perl/blob/42b0094646/pddtypes.pod

perl types pod

https://github.com/rurban/perl/blob/05514649c/pod/perltypes.pod

perldata.pod: add const and coretypes

https://github.com/rurban/perl/commit/7eb6c3584a1b

B::CC or another optimizing compiler can only profit from const and types.

After the YAPC we'll gather in Stavanger, Norway to discuss how to get the MOP proposals into perl.

http://act.yapc.eu/mtmh2012/

https://github.com/stevan/p5-mop/tree/master/extras/talks

Of course a MOP will slow down perl (other disagree), but as perl is currently hardly optimizable at all and more and more slowdown is getting introduced over the years, the MOP could be used to allow more compile-time optimizations and more efficient class, method and property handling.

Getting an optimizing compiler for YAPC::US sounds like a good plan to me, but is of course way too optimistic. B::CC already exists and passes most tests. Fixing the failures sounds like a good plan to me.

Function calls are also super-slow with perl. Getting faster functions calls by analyzing the code at compile-time and omit unnecessary exception handling, @_ handling, scope, and so on would also be a worthwile goal, up to inlining. Unfortunately it is not possible to discuss such thing on p5p. Not even the much simplier, possible XS call improvements.

The next idea will be Go-like concurrency in p5 with a changed runloop to saturate multiple native threads on multiple CPU's automatically. And some go-like language extensions for IPC communication. But I guess this vision is way too much for p5p. And even parrot is not there yet. In the current p5p process environment hardly anything could get done. It's management anti-patterns all over, as from the textbook.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.