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