Colin Campbell <c...@shaw.ca> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel