possible reason for slowness with Guile 2.2?

[Jonas Hahnfeld]

Continuing the discussion from 
https://gitlab.com/lilypond/lilypond/-/merge_requests/225: One of the
remaining reasons for slower execution times with Guile 2.2 appears to
be the output framework. Comparing the runtime of Paper_book::output
for MSDM.ly shows around 1 second for Guile 1.8, but more than 7
seconds with Guile 2.2, from a total of ~30 seconds (Guile 2.2). Note
that this includes the time for Ghostscript!

After looking into some profiles, I think this is in large parts due to
Paper_outputter::output_stencil which eventually calls scm_eval
from Paper_outputter::scheme_to_string. That's nothing new and has been
suspected to be the reason. However, Han-Wen reports that switching to
Guile 3.0, which is supposed to significantly improve the performance
of scm_eval, does not change much and it's still slower than Guile 1.8.

As far as I currently understand, LilyPond calls scm_eval for every
stencil which might be many (several thousands per page for MSDM.ly, up
to ~4000 for a very crowded score of mine). To verify, I wrote attached
micro-benchmark that calls scm_eval for the expression (+ 1 2)
1,000,000 times. Compiled with $ gcc -O2 -Wall eval.c -o test -lguile,
I see ~2.7s for Guile 1.8. With -lguile-2.2 this explodes to 36s! I
don't have an installation of Guile 3.0 around (please share if you
have), but would expect similar results.

For MSDM.ly, I see a total of 191251 calls to scm_eval from
Paper_outputter::scheme_to_string which pretty much agrees with the
slowdown of 6-7 seconds. So could it be that we're hit by the overhead
of scm_eval instead of the mere execution speed (which seems to be
negligible)?

Jonas

signature.asc
Description: This is a digitally signed message part