Re: guile-2.0 and debian

[David Kastrup]

Thomas Morley <address@hidden> writes:

> 2016-11-25 23:19 GMT+01:00 Antonio Ospite <address@hidden>:
>
>> - Investigate why lilypond is a lot slower when using guile-2.0
>
> This is the current main problem, I'd say.

I think it most likely that it is a distributed problem.  My personal
recommendation would be to put this last and get a working LilyDev and a
compiling LilyPond so that the problem becomes reproducible by following
a very short list of instructions.

Once you are there, get the Guile developer list involved.  They are
_obsessed_ with performance improvements and a performance regression by
more than a factor of 3 in an actual real-world use of Guile as an
extension language will be rather off-putting to them.  The default
reaction will be "you must be doing something wrong".

For that reason it will be important that there is a very short list of
instructions for reproducing and testing the problems (including a good
test case).

Because "with Guile-2.x, there is no longer a way to do the job right
that Guile-1 was perfectly fine for" would certainly also be a result
that they would need to think about.

It's possible that managing .go files smartly will help, but the point
is that Guile-2 does not really offer facilities for doing so that would
work out of the box and it would be foolish to expect everyone using
Guile for extensions to create a whole .go file managing infrastructure.

Another thing is that Guile-2 makes passing information in and out of
strings and string buffers expensive because of having to convert
between encodings every single time.  Again, for a pervasive extension
language this just doesn't cut it, and LilyPond passes a lot of strings
and symbols back and forth from Guile.

> Probably worth adding:
>
> (display (make-simple-markup "xy"))
>
> results in:
>
> 2.19.51:
> (#<procedure simple-markup (layout props str)> xy)
>
> 2.19.52-guile2
> (#<procedure simple-markup (a b c)> xy)
> Which is technically correct but not helpful.

I don't think that we can do anything here except possibly not produce a
procedure in the first place but rather a callable Guile structure, with
its own print procedure consulting the documentation string (which
contains the actual arguments these days I think since I already got
bitten by this in the course of Guile-2 conversion and autogeneration of
the Internals Reference: it's not like I haven't done any Guile-2
conversion work previously).

But that would come at some cost.  It would also make sense to remove
the "layout props" parts of the arguments similar to "parser location"
have been removed.

And while one is at it, unify markups and markup lists.  And so on.

-- 
David Kastrup