lilypond-user
[Top][All Lists]
Advanced

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

Re: Frescobaldi slowed down [WAS: Re: Emacs lilypond mode formatting and


From: Urs Liska
Subject: Re: Frescobaldi slowed down [WAS: Re: Emacs lilypond mode formatting and indenting]
Date: Mon, 28 Jan 2019 09:02:22 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1


Am 28.01.19 um 08:18 schrieb Andrew Bernard:
Hi Urs,

I split my score into files only ten pages long to avoid the issue to begin with, but it suddenly started happening. Perhaps some Debian 9 Python change?


Other than with LilyPond the issue is not the complexity of the *score* but that of the *input files*, which correlates typically but not always.

I had this problem with two projects: one was a huge (150 page) orchestral score that was organized in >5.000 input files, the other had very short 2-3 page songs with one large input of several thousand lines each because (from auto-converted input) every element had a "\tweak id".

The basic error here in Frescobaldi's code is that (I think) upon every change the whole document is parsed again (following all includes) to provide the data for autocompletion and syntax highlighting. As this happens in the single application thread this is blocking everything else.

Essentially there should only be two (minor) things to be done to completely and instantly make the problem go away:

  • Make sure that the used data structure is only updated in the background
  • Make sure only *modified* parts of it are updated

While this is conceptually pretty clear I haven't dared yet to investigate it in the code base yet because I haven't understood yet how Frescobaldi actually does its highlighting. But I recently changed the way Frescobaldi handles external jobs/processes, and that might make it more straightforward and compartmentalized to approach the issue.

I can't afford starting this but if you (well, or anyone else) would be interested going after it I'd certainly be there to assist.

Urs


Andrew


On Mon, 28 Jan 2019 at 18:01, Urs Liska <address@hidden> wrote:

Am 28.01.19 um 07:51 schrieb Federico Bruni:
> Il giorno dom 27 gen 2019 alle 1:58, Andrew Bernard
> <address@hidden> ha scritto:
>> But since an upgrade to Debian 9 and as the complexity of my current
>> score increases, F. has slowed down to a molasses like rate and has
>> sadly become unusable.
>
> Are you sure that it was caused by an upgrade to Debian 9? Did you
> upgrade Frescobaldi as well? How did you install Frescobaldi?
>
> Perhaps Frescobaldi is becoming slow only when you work on very big
> scores or files that includes several large files? See this issue:
> <https://github.com/frescobaldi/frescobaldi/issues/473>
>

I would also think that this problem is *not* related to a change in the
Linux distribution but *only* to the complexity and size of the input
files. The issue Federico links to is exactly the problem.

Fixing this issue should be comparably low-hanging fruit, especially
with some new code providing better control over external background
jobs. So maybe tackling *this* would give you earlier results ;-)

Urs


_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user

reply via email to

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