resent since topic was off-topic...
On Thu, 15 Jul 2010 00:34:40 +0200, Arno Waschk <hamama...@gmx.de> wrote:
On Wed, 14 Jul 2010 21:21:28 +0200, Joe Neeman <joenee...@gmail.com>
wrote:
On Wed, Jul 14, 2010 at 9:49 AM, Arno Waschk <hamama...@gmx.de> wrote:
On Wed, 14 Jul 2010 13:27:53 +0200, Arno Waschk <hamama...@gmx.de>
wrote:
On Wed, 14 Jul 2010 01:53:21 +0200, Joe Neeman <joenee...@gmail.com>
wrote:
On Tue, Jul 13, 2010 at 2:55 PM, Neil Puttock <n.putt...@gmail.com>
wrote:
Hi Joe,
On 13 July 2010 02:18, Joe Neeman <joenee...@gmail.com> 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/
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
