[Top][All Lists]

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

Re: Lilypond speed (was Re: How to make GNU Guile more successful)

From: Thomas Morley
Subject: Re: Lilypond speed (was Re: How to make GNU Guile more successful)
Date: Thu, 9 Mar 2017 00:17:12 +0100

2017-03-06 21:41 GMT+01:00 Andy Wingo <address@hidden>:
> On Sun 05 Mar 2017 15:01, Thomas Morley <address@hidden> writes:
>> Here some timing values
>> (1)
>> lilypond-2.19.52 using guile 1.8.7
>> (I would have prefered to build lilypond with a guile-1.8.8 build from
>> the guile-repository. Though my try to build it from the
>> branch_release-1-8 failed. Instead attempting to fix it, I then used a
>> released lilypond-version)
>> real    8m16.191s
>> user    6m39.864s
>> sys    0m10.860s
>> (2)
>> guile-2.0.14 build from guile-git-repository, branch 
>> remotes/origin/stable-2.0
>> lilypond-2.19.56, build from local branch dev/guile-v2.2-work
>> real    34m11.762s
>> user    45m11.316s
>> sys    0m5.604s
>> (3)
>> guile-2.1.7 build from guile-git-repository, branch master
>> (I've got this warning:
>> configure: WARNING: *** GNU Readline is too old on your system.
>> configure: WARNING: *** You need readline version 2.1 or later.
>> No idea whether this may have an impact on lilyponds compiling-time
>> I'll have to test.)
>> lilypond-2.19.56, build from local branch dev/guile-v2.2-work
>> real    67m29.132s
>> user    93m14.812s
>> sys    0m7.332s
> Oh, that's interesting.  IME the only thing that is slower on 2.2
> compared to 2.0 is the compiler; everything else is significantly
> faster.  Could it be that Lilypond is spending time compiling things
> somehow?  Perhaps via scm_load without disabling autocompilation or
> something?  Guessing at this point tho.

At least git-grepping for scm_load inthe lilypond-repository returns nothing.

> But that's getting ahead of myself -- do you have a document that
> exhibits a similar performance series (1.8 < 2.0 < 2.2) but which
> doesn't take so long to run?  That can make perf investigation a bit
> more tractable :)
> Andy

Attached you'll find
Two overrides, foo and fooI, are defined to show embedding lily in
guile and vice versa as well as some simple string-operations.
(The overrides themselves print silly things, but it's typical
user-generated code, just to demonstrate the method)
Below you'll find timing values for lilypond with guile 1.8.7, 2.0.14 and 2.1.7.
Those three lily-versions are tested without foo and fooI, with foo
and with foo _and_ fooI

lilypond 2.19.56 guile 1.8.7

real    0m2.207s
user    0m2.120s
sys        0m0.076s

with foo:

real    0m6.707s
user    0m6.336s
sys        0m0.372s

with foo and fooI:

real    0m9.749s
user    0m9.268s
sys        0m0.472s

lilypond 2.19.57 guile 2.0.14

real    0m11.843s
user    0m12.452s
sys        0m0.172s

with foo:

real    0m34.020s
user    0m35.284s
sys        0m0.168s

with foo and fooI:

real    0m38.819s
user    0m40.020s
sys        0m0.396s

lilypond 2.19.57 guile 2.1.7

real    0m8.594s
user    0m9.424s
sys        0m0.180s

with foo:

real    0m14.626s
user    0m15.924s
sys        0m0.204s

with foo and fooI:

real    0m19.422s
user    0m20.960s
sys        0m0.304s

So guile 2.1.7 is indeed faster than 2.0.14 with this test-file, otoh
I've redone testings with the other file and can confirm 2.1.7 being
slower there.
Currently I've no clue why.

Btw, I've improved my local setup to be able to test lilypond more
quickly with different guile versions. Though I wasn't able to compile
1.8.8, neither from the repository nor from the tarball downloaded
Due to:
async.c: In function 'scm_i_queue_async_cell':
async.c:243:14: error: variable 'count' set but not used
       size_t count;

Am I missing something?
I'm aware noone is interested in developing 1.8.8 further, though I
would have prefered to build lilypond with that version as well, like
the other test-versions.


Description: Text Data

reply via email to

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