On Tue, 2024-04-02 at 16:40 +0200, Michael Käppler wrote: > Am 01.04.2024 um 22:03 schrieb Jonas Hahnfeld via Discussions on LilyPond > development: > > As pointed out by Han-Wen in November, this is actually fairly little > > code that gets dropped; we need to keep some related to optimizations > > for compatibility with 3.0.0 up to 3.0.2; see also below. > > Just to share some numbers: It is still the case with current Guile master, > that bytecode compilation is nearly 10x slower with the default optimization > level than > with optimizations switched off. > > make bytecode with default optimization level: > real 2m0,875s > user 1m59,989s > sys 0m0,796s > > make bytecode without optimizations: > real 0m16,535s > user 0m14,209s > sys 0m0,810s > > What concerns LilyPond processing speed, I did a comparison with the > medium-sized score > I also used for the JIT vs. non-JIT timings on Windows and got for 10 > subsequent runs: > > Without optimizations: > real 9m1,511s > user 8m52,375s > sys 0m11,423s > > With default optimization level: > real 8m34,762s > user 8m23,027s > sys 0m14,562s > > That would be -5% in compilation time. Does not pay off, I think.
Thanks for testing! I assume this is also enabling Guile optimizations during LilyPond runtime? It would be interesting to see if there's a gain from just compiling the bytecode with optimizations. That would be a one-time cost that may be worth paying, especially if we had proper standalone bytecode compilation that parallelizes... Jonas
signature.asc
Description: This is a digitally signed message part
