[EMAIL PROTECTED] writes:
> Something simply has to be done about lily's speed!
>From your perspective, yes. From my perspective, `simply' is not the
operative word.
To begin: I think the main problem with LilyPond is not its speed
(although that may contribute. You did compile with --enable-optimize,
right?) but the amount of memory it is using. The moment that the
footprint grows larger than your available RAM, swapping will
dramatically slow things down.
Compared to other music typesetters, LilyPond is much more flexible.
This flexibility is paid in memory usage; for example in Finale stem
directions are set using two bitfields of some 32-bit number of a stem
object. In LilyPond, it is done by prepending a cell containing
(cons direction 1) .. (or -1, whatever).
this costs 2 8-byte cells (ie. 128 bits), which is more than 50 times
the amount that Finale uses. It is also easy to see that the LilyPond
way is more flexible (We use association lists, created on the fly,
which means that we can accomodate for an almost infinite number of
arbitrary settings)
[Hint for Jan: We could try to implement a special 3-tuple for the
alists to bring this down to 1.5 cell per property, but I wonder how
much this brings us. I also have some ideas about how to change the
way \property works, to share settings across objects (right now, each
object with a \property settings uses its own alist entry, wasting
memory). It's also a good time to clean up paper and engraver blocks
to dispose of unused variables.]
Part of the memory used by Lily is used and recollected through GUILE
(A scheme interpreter). Unfortunately GUILE's garbage collection (the
process of finding discarded and therefore reusable memory) is
suboptimal, and leads to swapping. People are developing a replacement
(so called generational GC), but unfortunately, it's not here yet. The
only thing you can do now is twiddling with GUILE's memory settings.
(e.g.
GUILE_INIT_SEGMENT_SIZE_1 and
GUILE_MAX_SEGMENT_SIZE.
I added a faq entry about this.
You could ask around on the GUILE mailing list, see
http://www.gnu.org/software/guile/. Don't forget to ask nicely about
the generational GC as well)
Memory usage is a form of profiling, and it is therefore black
magic. I honestly don't know what in LilyPond is taking up all the
memory, and I don't have many tools to find out. If someone manages
to run LilyPond in a memory profiler, please please please send
me results.
As you can see, I have some ideas, and some ideas for solutions. My
experience however shows that more than half of my ideas about this
type of problem are wrong. This makes me reluctant to chasing it, and
it also means that I really can't promise anything.
In short: I'd love to help you out, but I don't know if I can. I'll
try though (when I'm back from my conference this week)
(BTW, you can remove the bar number engraver from score context, to
knock off a bit from the more memory usage.)
--
Han-Wen Nienhuys | [EMAIL PROTECTED] | http://www.cs.uu.nl/~hanwen/
