lilypond-devel
[Top][All Lists]
Advanced

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

Let's speed up lilypond! was: scheme night-mare...


From: Arno Waschk
Subject: Let's speed up lilypond! was: scheme night-mare...
Date: Thu, 15 Jul 2010 00:36:13 +0200
User-agent: Opera Mail/10.60 (Linux)

resent since topic was off-topic...

On Thu, 15 Jul 2010 00:34:40 +0200, Arno Waschk <address@hidden> wrote:

On Wed, 14 Jul 2010 21:21:28 +0200, Joe Neeman <address@hidden> wrote:

On Wed, Jul 14, 2010 at 9:49 AM, Arno Waschk <address@hidden> wrote:

On Wed, 14 Jul 2010 13:27:53 +0200, Arno Waschk <address@hidden> wrote:

 On Wed, 14 Jul 2010 01:53:21 +0200, Joe Neeman <address@hidden>
wrote:

 On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock <address@hidden>
wrote:

 Hi Joe,

On 13 July 2010 02:18, Joe Neeman <address@hidden> wrote:

> Does the attached patch help? For me, it reduces dramatically the
> number of times that combine_pure_heights (and also ly_scm2interval) > is called, but it has very little effect on lilypond's overall running
> time (for the optimized build, at least).

I've just tested this patch (after removing the bits which prevented
it from applying; they look like they belong to a fix for issue 1152.
:)  It has a dramatic effect in several cases: on one 26 page score
it's halved the compilation time to just over a minute.


Ok, it seems like I should be benchmarking with bigger files; I was just
trying mozart-hrn-3 :) I'll clean up the patch a bit a post it on
rietveld.

Cheers,
Joe


Hi, with Joe's patch i got with my actual project's big score close to 25%
reduction on lilypond run time, which is very nice!
After git pull origin (onto Joe's patch) i got:


Zeilenumbrüche werden berechnet...terminate called after throwing an
instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted

Can somebody help me?

Thanks, Arno


seems this is something which is new (i tried as well 2.13.26).
it just meens that the swap partition is full...

looks my score is too long for lilypond, or too many accidentals?

the following:


\version "2.13.28"
\layout { ragged-right = ##t }

\relative c' {
       \key a \major
\repeat unfold 1000 {
       f8 g f g fis gis a a
       f8 g f g fis gis a a
%\pageBreak
       f8 g f g fis gis a a
       f8 g f g fis gis a a}
c r r4 r2
}


dies in Accidental_placement::get_relevant_accidentals

where etls.size is reported as 16000 in the loop. On my machine at i~13000,
4 GB memory, 2 GB swap space...


I just fixed a bug which caused memory consumption and time that is
quadratic in the number of accidentals, so this example should work much
better now.


but was i actually had wanted to try was the question whether the layout goes quicker with manual page breaks (since i thought that would lead to lily only be looking for layout issues within two manual pagebreaks ...!?)
which is does not seem to.
playing with the repeat factor shows nice quadratic time growth, and hardly
a difference whether the \pageBreak is commented out or not...


As per the discussion on bug 884, \pageBreak no longer speeds up the
page-breaking computation.

Cheers,
Joe

Wow! First impression is huge running time reduction. Rough guess 80% for my large score. So 400% performance gain... But in the end it dies again with that memory error, but i wll check for that. In my little example it dies differently, obviously an endless loop in grob-smob.cc:50 according to an endless backtrace in gdb.

Hope that helps?

Yours, Arno


--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/



reply via email to

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