[Top][All Lists]
[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