Carl Sorensen <c_soren...@byu.edu> writes: > On 7/30/11 2:19 PM, "David Kastrup" <d...@gnu.org> wrote: > >> >> >> Hi, >> >> music_list in parser.yy temporarily maintains an awkward >> half-self-referential data structure in order to have "fast append". It >> makes more sense in my opinion to use prepend and reverse afterwards. >> "Fast append" in theory may show minimally better cache coherency at the >> cost of uglier code and uglier data structures. So I'd just like to do >> the following (no full regtest yet). >> >> Comments? >> > > It seems to me that this change may lead to larger guile memory usage, as > well.
Why? scm_reverse_x works in-place. So you use one cons cell _less_ while a music_list is being assembled. And have a data structure that is friendlier to the garbage collector. > However, I think that where we have claims that something is done for > speed, we need to have a comparison that shows how speed is affected > when it's changed, before we can accept the change. I don't claim to do this for speed. > So in principle I'm in favor, but I'd like to see the affect on speed and > memory usage, both with the regtests and with a large score. There was no noticeable effect on speed either way for a laaaaarge music list. If any, it was better, but the average change was quite smaller than the variation between identical runs. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel