"Keith OHara" <k-ohara5...@oco.net> writes: >> On Dec 13, 2013, at 9:07 AM, Keith OHara <k-ohara5...@oco.net> 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 <d...@gnu.org> > 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
