[Top][All Lists]

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

Re: problems with long files

From: Joe Neeman
Subject: Re: problems with long files
Date: Thu, 3 May 2007 08:26:01 +1000
User-agent: KMail/1.9.5

On Wednesday 02 May 2007 23:03, Arvid Grøtting wrote:
> 2007/5/2, Joe Neeman <address@hidden>:
> > With my working copy of lilypond (on a 1.6 GHz Opteron), I have this down
> > to 3m22.321s. That's still about 3 times slower than 2.8 but it's
> > progress. FWIW, I don't think 2.10 (and above) will ever be as fast as
> > 2.8 when there are many scores -- the newer versions do a lot more work
> > in the page-breaking stage and there is a limit to how much it can be
> > optimised.
> Personally, I'm not at all worried about a constant-factor increase in
> running time.  The trouble, at least with 2.11.23, is that the running
> time scales very badly with the number of scores (or possibly more
> generally with the total length of the music).
> As I said, 26m5.898s user time for the problematic file (here), with
> 29 score blocks.  With roughly half the score blocks commented out,
> I'm down to 2m44.806s user time for 14 score blocks. Halve again, and
> I'm at 0m47.255s for 7 score blocks.  A single (the first) score block
> clocks in at 0m3.020s user time.
> Something tells me this is a bit worse than O(n).

With the optimisations, it scales like (left column is the number of scores)
24 2m0.017s
19 1m23.650s
14 0m52.611s
9 0m27.961s
4 0m11.139s
1 0m4.402s

as you can see, it isn't O(n) but it isn't much worse either. The further 
optimisations I have planned should make it even closer to linear.

reply via email to

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