Re: Context.Grob considered as symbol list

[David Kastrup]

Colin Campbell <address@hidden> writes:

> On 12-10-09 12:59 PM, David Kastrup wrote:
>> Since this patch series is a bit humongous for reviewing in a single
>> Rietveld review and it would take two months to get every patch in
>> sequence through an individual review, I am putting this series out as
>> an experiment to the list.
>>
>> Let's see how we fare.
>
> How do you want to handle countdowns for this patch, David?  I suspect
> the discussion might get rather technical, and I would have to rely on
> your judgement as to when sufficient consensus has been reached for
> the countdown step.  There are several reviewers commenting on
> Rietveld, which would ordinarily be enough for me to go to countdown,
> but are you looking for explicit comment on each element in the
> series?  I wouldn't think it inappropriate if you put the patch on
> countdown yourself, when you feel it has had proper discussion.

There is rarely such a thing as a "proper discussion".  Three quarter of
the patches in the series are straightforward simple rearrangements that
I'd have no qualms pushing without any indication of interest.  Of the
remaining patches, half create more natural/nicer user interfaces for a
number of existing functions.  The rest introduces conceptually a
uniform concept of LilyPond syntax of which the existing language has
"regional dialects" in different areas which, after this change, can be
exchanged.

Now the question is what the performance impact of this new part of
LilyPond constructs with some ambiguity is.

If you compare the execution time of the classic


#(do ((i 0 (1+ i)))
  ((> i 100000))
  #{ \override Accidental #'color = \red #})

with

#(do ((i 0 (1+ i)))
  ((> i 100000))
  #{ \override Accidental color = \red #})

of course the cost of calling the LilyPond parser a hundred thousand
times is going to dominate the execution time.  However, there is still
a significant difference (5-10%) between the two.  The latter is faster.

Now of course the comparison is not fair since I was using the same
LilyPond version, and so the machinery for sifting through various types
of strings and symbols was at work in either case.  However, the point
is that switching to the Guile interpreter may be cheap, but it is not
zero price, so for the actually trivial stuff like symbols even with the
necessary resolution of ambiguities, a native LilyPond equivalent to
symbols buys us performance as well.

It is not likely to matter much in practice, but in this case there is
not even a tradeoff between convenience and performance involved, and
that makes for some incentive to move to LilyPond-native representations
even while they are optional.

-- 
David Kastrup