Re: State of LilyPond with Guile 2.2

[Han-Wen Nienhuys]

On Sun, Apr 11, 2021 at 3:42 PM Jonas Hahnfeld via Discussions on LilyPond
development <lilypond-devel@gnu.org> wrote:

>
> All numbers are from my laptop running Arch Linux (with pango
> downgraded to 1:1.48.2-1 to keep out the memory hogging in 1.48.3) and
> measured with "/usr/bin/time -v". I use commit fce156f219 from
> https://gitlab.com/lilypond/lilypond/-/merge_requests/723 (see User's
> View) and the system-provided versions of Guile 1.8.8 and Guile 2.2.6.
> I don't test Guile 3.0 because it's not available as package, and there
> seem to be more changes needed to make it even work.
> I configured the build with --enable-gs-api (because I'm interested in
> the time spent in LilyPond, not how fast the system can fork gs)
>

I assume this is also without extractpdfmark, which is also a CPU hog.


> The first set of experiments is about things that developers care
> about, namely 'make test' and 'make doc'. For all runs, I used the
> options "-j4 CPU_COUNT=4".
>
> 'make test' when compiled with Guile 1.8.8:
>  * User time (seconds): 520.68
>  * Elapsed (wall clock) time (h:mm:ss or m:ss): 3:59.54
>

IIRC, on my 4 CPU machine, the actual time running the regression .ly files
is fairly low (about 1 minute). A lot of time is spent running the
lilypond-book regression tests, which makes this difference all the more
dramatic


>  * Maximum resident set size (kbytes): 372560
> 'make test' when compiled with Guile 2.2.6:
>  * User time (seconds): 710.35
>  * Elapsed (wall clock) time (h:mm:ss or m:ss): 5:43.04
>  * Maximum resident set size (kbytes): 372344
>
> -> 40% slower when using Guile 2.2.6 during development
>

I didn't see you mention this explicitly: for apples to apples comparisons,
you have to disable 'debug-gc-object-lifetimes feature. It causes a
significant slowdown with Guile 1.8 for make test/make doc, so the
comparison is probably worse.

This comes at the expense of increased memory usage (which reduces GC
overhead), so you'd have to test with my GUILE patches for a completely
honest comparison. I think the advantage of the decreased GC overhead is
minor, though.

In my opinion, the numbers show that we *must have* compiled bytecode
> for user installations in order to reach acceptable performance (memory
> usage seems to be fine). And while compilation by invoking LilyPond is
> somewhat odd, it works and would be viable for the beginning.
>
> For development, I'm less convinced. Sure, 'make test' and 'make doc'
> get faster but the compilation itself takes a considerable amount of
> time. Moreover it is my understanding the Guile is notoriously bad at
> determining which files to recompile, in particular when macros are
> involved.
>
> Personally, I would be ok with the moderate slowdown if that was the
> only thing preventing a hypothetic switch to Guile 2.2, and the arising
>

What does "switch to" mean precisely? Do you mean "remove support for guile
1.8", "make 2.2 the default (when given the choice) but keep supporting
1.8" ?


> question is really a matter of prioritizing: There are other items that
> need solutions before that switch could happen (in particular the
> release process for binary builds and documentation). What do others
> think? Or would you say that proper bytecode compilation is required
> before moving to Guile 2.2? (with no clear estimate how feasible that
> is and how long it would take)
>

How hard is it really to byte-compile the files during the build? Could we
run lilypond during the compile and collect the .go files? Are they
architecture independent (could we still cross-compile to windows?)

Sorry for the long and densely packed message, and thanks for reading
> to the end!
>

no worries, thanks for taking the effort to sort this out!

-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen