lilypond-devel
[Top][All Lists]
Advanced

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

GUILE 2.2 progress


From: Han-Wen Nienhuys
Subject: GUILE 2.2 progress
Date: Sat, 25 Jan 2020 13:47:43 +0100

With https://codereview.appspot.com/551390047/
it looks like I can run LilyPond against GUILE 2.2 mostly:


$ time lilypond input/regression/mozart-hrn-3.ly
GNU LilyPond 2.21.0
Import (ice-9 threads) to have access to `call-with-new-thread'.
Import (ice-9 threads) to have access to `current-thread'.
Processing `input/regression/mozart-hrn-3.ly'
Parsing...
input/regression/mozart-hrn-3.ly:31:9: error: not a markup

        #(string-append  "It has been typeset and placed in the public "
Interpreting 
music...[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120]
Preprocessing graphical objects...
Interpreting music...
Interpreting music...
Interpreting music...[8][16][24][32][40][48]
Preprocessing graphical objects...
Interpreting music...
Interpreting 
music...[8][16][24][32][40][48][56][64][72][80][88][96][104][112][120][128][136][144]
Preprocessing graphical objects...
MIDI output to `mozart-hrn-3.midi'...
MIDI output to `mozart-hrn-3-1.midi'...
MIDI output to `mozart-hrn-3-2.midi'...
Finding the ideal number of pages...
Fitting music on 3 or 4 pages...
Drawing systems...
Layout output to `/tmp/lilypond-A2ssuI'...
Converting to `mozart-hrn-3.pdf'...
Deleting `/tmp/lilypond-A2ssuI'...
fatal error: failed files: "input/regression/mozart-hrn-3.ly"

real 0m7.239s
user 0m8.637s
sys 0m0.121s

(this disables the GS step, as something is munging a string , causing
GS to barf.)

7.2 seconds end-to-end includes 1.7s of GC, and 2.0s of reading/compiling SCM.

On guile 1.8, with GS disabled, the end to end runtime is

3.568s including 0.33s for GC and 0.32s for reading the SCM.

These timings are internally consistent: if we can do byte-compilation
on the .scm files (which would make the SCM reading instantaneous),
and get the GC overhead down, we'd be at the same performance level of
GUILE 1.8.

What do folks think is more important? Reducing GC overhead is a win
on large scores, while byte-compilation will make compile/edit/debug
cycles faster.

Even if we wouldn't recoup all the overhead of GC, I think the reduced
complexity of using BGC for GC might be worth it.

I think it is clear that we should not be targeting GUILE 2.0, but GUILE 2.2.

-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen



reply via email to

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