(please CC replies directly to me; I am not on the guile-devel list.) Arne mentioned
>This might be the read-function which is slower in 2.2. You might want >to try to go directly to Guile 3, in which the read function should be >on par with the read in 1.8. I'd rather avoid making a jump to GUILE 3, as it's not in distributionsn yet. Just to be extra clear: if I instrument Lily with (begin (display "gc time taken: ") (display (* 1.0 (/ (cdr (assoc 'gc-time-taken (gc-stats))) internal-time-units-per-second))) (display "\n"))) this number increases from 0.3 to 1.7. Parsing and compiling the .scm files in our distribution has a GC overhead of 0.3 by itself on GUILE 2.2 The release notes for 2.0 say that "Switch to the Boehm-Demers-Weiser garbage collector .. It also improves performance." I am curious about the numbers that support this; can somebody point me to them? From where I stand, it looks like a huge performance regression. On Tue, Jan 28, 2020 at 11:41 PM Han-Wen Nienhuys <hanw...@gmail.com> wrote: > > Hi folks, > > after a long hiatus I have started getting involved with LilyPond > again, and one of the things I'd like to do is get LilyPond off GUILE > 1.8. Experiments suggest that starting from GUILE 2.2, the execution > performance is on par with 1.8. There are 2 open issues: caching byte > compiled files (which I haven't looked into yet), and GC. > > Unfortunately, it looks like the adoption of the BDW GC library caused > a ~6x slowdown, causing an overall end-to-end slowdown of 50%. > > I was wondering if you folks would have tips to further tune GC for > wall-time speed, and if there additional diagnostics to see if we're > doing something extraordinarily silly. > > I already found the GC_free_space_divisor, but I already tuned to its > fastest value, 1. > > -- > Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen