Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Re: Trading compile time for faster runtime?

by dave_the_m (Monsignor)
on Apr 21, 2022 at 08:23 UTC ( [id://11143161] : note . print w/replies, xml ) Need Help??

in reply to Trading compile time for faster runtime?

The easy bit is adding a compile-time switch to say "do more optimisations". The harder bit is deciding what new optimisations could be added under that umbrella. The hardest thing is actually implementing those optimisations in a way that doesn't break everything, once you take all the quirks of perl into account, such as tieing, magic, tainting and overloading. The impossible bit is finding people with enough knowledge of those quirks and the perl internals to implement them. There's currently only a handful of people in the world with those skillsets, and we're already occupied with other stuff or coping with depression or whatever.

As an example, a few years ago I added the 'multiconcat' operator, which merges a series of concatenations (such as $x .= "-$y-") into a single op. Since the op can see the whole picture, it can be a lot more efficient - such as just allocating a final string buffer of the right size once, rather than repeatedly growing and reallocating the string. It should have been simple, but turned out to be really hard, and broke a whole bunch of CPAN modules. The runtime implementation of the multiconcat operator is about 700 lines of C code - it turns out that concatenating strings in perl is non-trivial.


  • Comment on Re: Trading compile time for faster runtime?

Replies are listed 'Best First'.
Re^2: Trading compile time for faster runtime?
by melez (Sexton) on Apr 21, 2022 at 09:38 UTC

    This is an excellent answer, thanks Dave. I suspected that might be hard, but not that hard. Yes, perl is very dynamic, and I imagine a lot of paths need to be repeated every time (so not really optimizable) just to make sure nothing changed, or else stuff breaks.