Re: Test reader speed of Guile 3.0.6

[Jonas Hahnfeld]

Am Freitag, dem 12.03.2021 um 23:40 +0100 schrieb David Kastrup:
> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
> 
> > Han-Wen Nienhuys <hanwenn@gmail.com> writes:
> > 
> > > On Wed, Mar 10, 2021 at 8:23 AM Dr. Arne Babenhauserheide
> > > <arne_bab@web.de> wrote:
> > > > there’s a Guile 3.0.6 release planned that includes a rewrite of the
> > > > reader in Scheme. It has speed in the same order of magnitude as the
> > > > previous reader but might have different performance characteristics.
> > > > 
> > > > If I remember correctly, lilypond uses the reader a lot, so if you have
> > > > a test-system with lilypond on Guile 3, could you test how running
> > > > lilypond with the current Guile master from git affects lilypond?
> > > 
> > > last time I looked, building GUILE 3 from source was truly glacial,
> > > making this kind of thing annoying to check.
> > 
> > If you build from tarball it is much faster, because it then provides
> > pre-created bootstrapping files. What’s so slow is creating the initial
> > optimized reader.
> > 
> > > You say "same order of magnitude". Do you have benchmarks so we know
> > > what to expect?
> > 
> > The current *average* spead of the reader is roughly 80% of the reader
> > implemented in C, but with different performance characteristics. I’m
> > asking here because I want to avoid surprising and avoidable changes
> > that block Lilypond. I consider Lilypond to be the most important
> > flagship project of Guile, and I want to do what I can to prevent
> > unnecessary friction.

IMHO not including a major rewrite of the entire reader into a bug-fix
release should have been the first step. Right now, if we asked for
guile-3.0 during configure time (which we don't), we would have no idea
which one we get. Really, there must be some truth to the idea of
semantic versioning...

> Sadly, you are not likely to block LilyPond.  The compilation
> instructions for LilyPond strongly recommend using version 1.8.8 (or the
> branch tip catered for by Thien-Thi Nguyen) since all other versions are
> vastly slower and less stable.
> 
> All reasonably workable versions of LilyPond do this.  The others are
> more like "proof of concept" installations provided by package
> maintainers that are not by themselves LilyPond users.  They are
> unusably slow and resource-intensive and have a tendency towards
> crashing and eating all memory for non-trivial scores.

I don't think the situation is that bad anymore. I've been trying hard
to fix bugs reported from distributions that attempted switching for
2.22 (telling them to go back to Guile 1.8), and current master is able
to run full 'make test/check' and 'make doc' when built against Guile
2.2. The only real issue is startup time without compiled bytecode, but
I hope to have some numbers on that soon-ish.

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