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
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.