Andy Wingo <wi...@pobox.com> writes:
> On Tue 28 Feb 2017 00:00, Thomas Morley <thomasmorle...@gmail.com> writes:
>
>> The main problems/TODOs are listed here (same for guile-2.0.13 and 2.1.7):
>> https://ao2.it/tmp/lilypond-guile2/TODO
>> With no warranty for completeness.
>>
>> Let me pick some of them:
>> (1)
>> lilypond filename_名字.ly
>> returns
>> fatal error: failed files: "filename_??????.ly"
>
> Interesting, I would have thought that there would be a difference
> between 2.0.13 and 2.1.7 due to GUILE_INSTALL_LOCALE; I assume you are
> in a UTF-8 locale and that file name is UTF-8?
>
>> (2)
>> Floating point numbers are different in some decimal digits.
>> Possible impact on spacing in a regression-test for utf-8.
>
> If you have more details on the floating-point issue, they are very
> welcome :)
>
>> (3)
>> Most imortant for users:
>> LilyPond slowed down dramatically. Today I tested a huge file:
>>
>> lilypond 2.19.52 with guile-1.8
>>
>> real 9m8.229s
>> user 6m41.156s
>> sys 0m11.940s
>>
>> lilypond 2.19.56 with guile-2.1.7
>>
>> real 48m45.225s
>> user 65m43.252s
>> sys 0m6.320s
>
> Do you have Guile 2.0 numbers as well?
>
> I understand that Lilypond uses the "local-eval" facility a lot for
> embedded Scheme.
It doesn't use it at all.
> This is a facility that was indeed faster in 1.8. I would expect that
> 2.1.7 would be faster than 2.0, if that were the case, as 2.1.7's
> evaluator is faster. Hard to say, though. That interface does not
> get a lot of speed attention. We could take a look and see what we
> can do. I guess we need some profiling first.
Moot. What used to be done with local-eval before we had to come up
with a replacement (at that time, it did not appear like the facility
would be available until the migration to Guile 2.0 was completed) is a
lambda capture: the _forms_ that would have been used in local-eval are
already with some reliability determinable at the time the environment
is captured, so instead of capturing the local environment, the forms to
be evaluated later are captured as individual lambda functions in that
environment.
The feature implemented in this manner is the #{ ... #} construct for
embedding LilyPond. It is used extensively but not likely in
performance-critical contexts.
Regular read and eval, however, is used a lot during the parsing of
files and startup of LilyPond. But at least under Guile-1.8, the
parsing and preprocessing took up a rather small part of the overall
runtime (in the order of 15% or so), so it is unlikely to be responsible
for the bulk of the slowdown.
My personal guess is that the largest performance impact at the moment
will be due to an absence of generation and installation of .go files.
Since .go files are target-dependent (if I am not mistaken) and LilyPond
is cross-compiled for a number of architectures with different byte
orders and type sizes, it seems tricky to get this under wraps.
The next largest performance impact will be redecoding issues.
> Can you run lilypond under callgrind under 1.8 and 2.1.7 and attach the
> generated callgrind.out.PID for each run? Run like this:
>
> valgrind --tool=callgrind --num-callers=20 lilypond foo.ly
>
> Thanks,
>
> Andy
--
David Kastrup
