lilypond-devel
[Top][All Lists]
Advanced

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

Re: GUILE 2/3 and string encoding cost


From: David Kastrup
Subject: Re: GUILE 2/3 and string encoding cost
Date: Thu, 23 Jan 2020 09:38:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Han-Wen Nienhuys <address@hidden> writes:

> On Wed, Jan 22, 2020 at 11:43 PM David Kastrup <address@hidden> wrote:
>
>> > Actually, the I was comparing the -O2 build with the -O0 build.
>> >
>> > When recompiling, the Scheme init (reading .scm files) takes 0.31s in 1.8
>> > vs. 2.7s in 2.0, a 9x slowdown.
>>
>> The Guile-2 compiler is doing a lot of optimisations, and LilyPond's
>> startup code switches off byte compilation because the dependencies are
>> hard to get under control.
>
>
> where does this happen?

lily/main.cc:     sane_putenv("GUILE_AUTO_COMPILE", "0", true);  // disable 
auto-compile

Took me a while to find again.

>> The current codebase at least manages to
>> avoid to compile code with as-yet undefined macros, something that
>> Guile-1.8 had no problems with but Guile-2.0 refuses.
>>
>
> Do you mean that we don't have them anymore, or is there something else
> going on?

The source code has been rearranged so that macros are defined before use.

>> So the Scheme loading speed is sort-of expected due to Guile relying on
>> byte compilation for speed and we switch it off.
>>
>>
> Much to the contrary. Byte-compiling is slow (but running it should be
> faster), something you can see from building guile. If it is switched off,
> we are getting the "fast" experience.

There is a difference between file-level compilation and other stuff.
But I don't know the details well.

-- 
David Kastrup



reply via email to

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