[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

possible reason for slowness with Guile 2.2?

From: Jonas Hahnfeld
Subject: possible reason for slowness with Guile 2.2?
Date: Sat, 25 Jul 2020 21:01:19 +0200
User-agent: Evolution 3.36.4

Continuing the discussion from 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 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, 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, 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


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]