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

Reply via email to