Thomas Morley <thomasmorle...@gmail.com> writes: > 2016-11-25 23:19 GMT+01:00 Antonio Ospite <a...@ao2.it>: > >> - 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel