Re: anyone notice speed of 2.17.95 on Windows ?

[David Kastrup]

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 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.

-- 
David Kastrup