Re: anyone notice speed of 2.17.95 on Windows ?

[Mike Solomon]

On Dec 10, 2013, at 12:18 PM, David Kastrup <address@hidden> wrote:

> Mike Solomon <address@hidden> writes:
> 
>> On Dec 10, 2013, at 11:47 AM, David Kastrup <address@hidden> wrote:
>> 
>>> Nope.  In this case, the answer is to cache frequently accessed
>>> information instead of requesting it again and again.
>>> 
>>> We don't want to give people a choice between different ways in which
>>> LilyPond will be bad.  We just don't want LilyPond to be bad.
>> 
>> In my initial patches, which involved caching everything, there was no
>> appreciable speed-up on Mac and Linux.
> 
> Maybe caching in unsuitable form?  Cached data should be in a form
> directly usable for processing (with some possible tradeoffs between
> memory impact and unpacking speed), not in the form that
> function/library/system calls will return it.

I had cached skylines, although it’s true that it is possible to cache results 
to function calls (i.e. calls to Skyline::distance for the exact same two 
skylines).

Or there may be a better way to cache the skylines.  But LilyPond takes a 
looottttt of time in Skyline distance calculations.

> 
>> I did not test it on Windows, but I don’t remember Windows users
>> (Janek) reporting back problems).
> 
> Well, sounds like hen-and-egg here: we need more serious users to give
> more definite feedback, so that we can make LilyPond more suitable for
> more serious users.
> 
>> I would be interested to do rigorous testing on Windows.  It is not
>> hard to do - it requires creating a Scheme hash linking glyph names to
>> skylines.
>> 
>> I still advocate allowing users to specify a speed/beauty tradeoff,
>> which can be done in concert with optimization to LilyPond’s core.
> 
> That makes only sense where there is an incurable reason for a large
> tradeoff.  "in concert with optimization to LilyPond's core" is, in my
> experience, a buzzphrase.  In particular the word "optimization" tends
> to be construed as "somewhat tune an unsuitable algorithm, making it
> inscrutable in the process".
> 
> I know that this use of "optimization" is widespread, but I have a
> thorough dislike for it.  Almost any task can be algorithmically cast
> into the n lg (n) category which, with modern processors, is usually
> doable without having to think about tradeoffs.
> 


I agree that the main goal should be speeding up the algorithm while 
maintaining, if not augmenting, its understandability.

Cheers,
MS