bug-lilypond
[Top][All Lists]
Advanced

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

Re: Lilypond taking forever to typeset


From: Mojca Miklavec
Subject: Re: Lilypond taking forever to typeset
Date: Tue, 12 Jul 2016 14:38:42 +0200

On 12 July 2016 at 13:25, David Kastrup <address@hidden> wrote:
> Mojca Miklavec <address@hidden> writes:
>
>> So here it goes ...
>>
>> (gdb) r test.ly
>> Starting program:
>> /Applications/LilyPond.app/Contents/Resources/bin/lilypond test.ly
>> warning: Tried to remove a non-existent library: 
>> /usr/lib/libstdc++.6.0.9.dylib
>> warning: Tried to remove a non-existent library: 
>> /usr/lib/libstdc++.6.0.9.dylib
>> ...
>> warning: Tried to remove a non-existent library: 
>> /usr/lib/libstdc++.6.0.9.dylib
>> Reading symbols for shared libraries
>> +++++++++..+...........................................................................................................................................
>> done
>> Reading symbols for shared libraries . done
>> GNU LilyPond 2.19.45
>> Reading symbols for shared libraries . done
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0x988f6e38 in memmove$VARIANT$sse3x ()
>> (gdb) backtrace
>> #0  0x988f6e38 in memmove$VARIANT$sse3x ()
>> #1  0x00b54b8f in cf2_glyphpath_moveTo ()
>> Previous frame inner to this frame (gdb could not unwind past this frame)
>
> Bah.  The innermost frame is just a memory copy, and the next one some
> font operation.  cf2 would be the Freetype2 library, Werner?
>
>> second attempt:
>>
>> ^C
>> Program received signal SIGINT, Interrupt.
>> 0x99885a62 in read$NOCANCEL$UNIX2003 ()
>> (gdb) backtrace
>> #0  0x99885a62 in read$NOCANCEL$UNIX2003 ()
>> #1  0x9891aee6 in __sread ()
>> #2  0x9891af0e in _sread ()
>> #3  0x9891b465 in __srefill1 ()
>> #4  0x9891bece in _fseeko ()
>> #5  0x9891b9a2 in fseek ()
>
> Completely useless (at least up to there, something else coming
> afterwards?), just a file seek.  We did already know that it was going
> through a lot of files.
>
> This does not really help us figure out what part of _LilyPond_ is
> responsible for triggering the font cache rebuild.
>
>> Let me know if there is anything else I could try or if I should
>> collect more "statistics".
>
> Some backtrace that actually starts somewhere in LilyPond would be good.
> So that would be a backtrace that actually ends somewhere in "main".

I probably need to recompile lilypond with debug info then. Here are
some more (useless?) traces:

#0  0x99885a62 in read$NOCANCEL$UNIX2003 ()
#1  0x9891aee6 in __sread ()
#2  0x9891af0e in _sread ()
#3  0x9891b465 in __srefill1 ()
#4  0x9891c189 in __fread ()
#5  0x9891c01f in fread ()
#6  0x00b34045 in FT_Stream_EnterFrame ()

#0  0x00b40bb6 in TT_Load_Simple_Glyph ()
#1  0x00b47e62 in load_truetype_glyph ()
#2  0x03818640 in ?? ()
Previous frame inner to this frame (gdb could not unwind past this frame)

#0  0x9988571e in open$NOCANCEL$UNIX2003 ()
#1  0x99884a98 in open ()
#2  0x988c62d9 in fopen ()
#3  0x00b2e6ae in FT_Stream_Open ()

>> This time the first lilypond run took 2,5 minutes to complete
>> (apparently I had additional problems with swap yesterday that
>> prolonged the process to almost 10 minutes).
>
> 2.5 minutes is still not great.  I'm wondering why LilyPond needs to
> entertain its own version of the font cache.

I don't see any viable alternative other than rewriting some portions
to use the native system library calls to get information about fonts.

Mojca



reply via email to

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