lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Anything speaking against this simplification?


From: David Kastrup
Subject: Re: Anything speaking against this simplification?
Date: Sun, 31 Jul 2011 00:08:59 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Carl Sorensen <address@hidden> writes:

> On 7/30/11 2:19 PM, "David Kastrup" <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]