Jean Abou Samra <j...@abou-samra.fr> writes:
> For one thing, Guile's optimization make about zero difference for the
> speed of the resulting LilyPond executable. For another, disabling
> optimizations in Guile 2 already results in a good speedup (1min
> to 20s), and while Guile 3 is even slower than Guile 2 at the default
> optimization level (1m30), with optimizations disabled it becomes
> near instant (3.5s).
>
> Guile 3 being far better at compilation speed with zero optimizations
> apparently comes from what is described in
>
> http://wingolog.org/archives/2020/06/03/a-baseline-compiler-for-guile
>
> On the other hand, it does look like Guile 3 is a little slower
> than Guile 2 on execution time (5%).
>
> What do you think?
I think where we ultimately want to end up is to have Guile use
optimisation for code loaded from .scm files (which should likely use
byte compilation) while not doing so for Guile code and definitions
invoked from .ly files with # and $ because those more likely than not
are not part of performance-relevant inner loops (and if they do, moving
them to .scm or otherwise specifically marking them might be a
reasonable requirement).
Note that "ultimately" does not mean that this may be the best strategy
right now. But LilyPond documents contain a huge amount of ad-hoc
Scheme code introduced with # (often as simple as a numeric constant or
quoted code that may warrant special-casing, and that actually _is_
special-cased within #{ #} passages already to avoid having to form
closures for it).
Of course your timings are quite encouraging here for seeing a path
forward but working out the details of what combinations make best sense
both in the short and the long run is likely going to need quite more
experimentation.
--
David Kastrup
