[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: possible reason for slowness with Guile 2.2?
From: |
Jonas Hahnfeld |
Subject: |
Re: possible reason for slowness with Guile 2.2? |
Date: |
Sun, 26 Jul 2020 10:57:39 +0200 |
User-agent: |
Evolution 3.36.4 |
Am Samstag, den 25.07.2020, 22:01 +0200 schrieb Han-Wen Nienhuys:
> On Sat, Jul 25, 2020 at 9:03 PM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> > Am Samstag, den 25.07.2020, 21:01 +0200 schrieb 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.
> >
> > Nah, forgot the attachment... here we go.
>
> For a representative benchmark, you have to create a list with a symbol and
> int literals; your benchmark also measures parsing time.
Agreed, see below.
> The output framework is one of the oldest pieces of Scheme infrastructure (if
> you follow its roots, you can find it in embryonic form in
> commit bac78d4e469b6f5612b51536165b0855284321ab from 1998). Using eval to
> translate a (symbol args) expression seemed like a good alternative to the
> symbol dispatch that the aforementioned commit had, but it isn't how I'd
> build it today.
>
> (Fun fact: lilypond once sported an ASCII art backend; look for AsciiScript
> in the git history. Adding Jan just to have another old fogey reminiscing of
> our lore)
>
> The question though is: what is a good interface? Existing code that
> interprets stencils look like a object with state (eg. the drawing context),
> and then do a dispatch on what symbol they encounter (see eg.
> interpret_stencil_for_skyline)
My naive approach was to just batch up all expressions into a list and
evaluate that. Hacked into LilyPond (see WIP attached) and seems to
work somewhat: Gives the same output a bit faster, but still slower
than Guile 1.8.
So back to the micro-benchmark (without parsing, only half the time):
$ gcc -O2 -Wall eval.c -o test -I /usr/include/guile/2.2/ -lguile-2.2
$ time ./test
real 0m18,086s
$ gcc -O2 -Wall eval.c -o test -I /usr/include/guile/2.2/ -lguile-2.2 -DLIST
real 0m8,607s
sounds good, but:
$ gcc -O2 -Wall eval.c -o test -lguile
$ time ./test
real 0m0,295s
$ gcc -O2 -Wall eval.c -o test -lguile -DLIST
$ time ./test
real 0m0,329s
Other ideas?
Jonas
> The recent discussion around making --safe the default are also relevant: if
> we split lilypond in two parts (the untrusted renderer and the trusted part
> that handles PDF/PNG conversion), we'd likely have to reorganize how Stencil
> expressions end up in PS files.
>
>
> --
> Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen
>
eval-list.diff
Description: Text Data
eval.c
Description: Text Data
signature.asc
Description: This is a digitally signed message part