Re: garbage collection slowdown

[Han-Wen Nienhuys <hanwenn@gmail.com>]

(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 <hanwenn@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 - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen



-- 
Han-Wen Nienhuys - hanwenn@gmail.com - http://www.xs4all.nl/~hanwen