On Dec 10, 2013, at 12:18 PM, David Kastrup <d...@gnu.org> wrote: > Mike Solomon <m...@mikesolomon.org> writes: > >> On Dec 10, 2013, at 11:47 AM, David Kastrup <d...@gnu.org> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel