lilypond-devel
[Top][All Lists]
Advanced

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

Re: anyone notice speed of 2.17.95 on Windows ?


From: David Kastrup
Subject: Re: anyone notice speed of 2.17.95 on Windows ?
Date: Sat, 14 Dec 2013 08:05:49 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

"Keith OHara" <address@hidden> writes:

>> On Dec 13, 2013, at 9:07 AM, Keith OHara <address@hidden> wrote:
>>
>>> Open_type_font:: and Pango_font::name_to_index() each call
>>> FT_Get_Name_Index().  Inserting print statements to trace those
>>> calls I find that FT_Get_Name_Index is called:
>>> 7 times for each character in a Tempo
>
> The layers of functions that result in repeated calls to the skylining code 
> have changed since the original skylines patch.  The latest change was
>
> author        David Kastrup <address@hidden>  
>        Thu, 21 Feb 2013 19:02:48 +0000 (20:02 +0100)
>  Issue 3200: Make ly:make-unpure-pure-container accept a single callback
>
>  Like with fixed values, this gets duplicated for the pure value as
>  well, but converted into a callback taking two more arguments (which
>  are ignored).

That was only creating a less awkward API for stuff that was already
being done at a number of places.  This patch should not have made a
performance difference in itself.

It might have encouraged and/or legitimized performance hogs.

> This type of unpure-pure-container is not a container of two functions
> but rather a single callback function, that promises to refrain from
> forcing line-break decisions (to be 'pure') and that ignores the two
> arguments giving the start- and end- of the line it would be on in the
> tentative line-breaks under consideration.
>
> In this case repeated calls will recompute the same value,

The point of this would appear to be that the calculation tracks the
changing placement of other elements depending on line-break decisions:
there would be no point in using an unpure/pure container in the first
place over a straight callback otherwise.

> so I see no reason to keep the function-call pointer in place after
> the first use.  So I suggest we treat this case as if it were a simple
> lookup of a property, rather than a 'pure' lookup.
> http://codereview.appspot.com/42190043

That does not make sense.  If you want call-once behavior, you can just
use a callback.

-- 
David Kastrup



reply via email to

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