Re: [PATCH] SBufList

On 12/02/2013 04:51 PM, Eliezer Croitoru wrote:
> On 03/12/13 00:54, Alex Rousskov wrote:
>> Yes, your "append into the unused MemBlob space if possible"
>> optimization is working well here. The accumulate-based solution still
>> feels rather fragile to me, but I do not have enough reasons to push for
>> a redesign.

> Eliezer Writes:
> And I am sure we can find a case which will cause a redesign.
> Once we can find two-three of these cases it will be strong enough to
> consider these.
>
> What kind of result can be felt as fragile?
> There is the worst case scenario of memory leakage which we are probably
> are not talking about.
> There is another worst case that can be identified by "slow" response.

In this context, "fragile" means that the implicit optimization might
stop working for some future version of the SBufContainerJoin() or
SBufContainerJoin-like code without us knowing. This particular use of
that optimization relies heavily on the fact that nothing happens to the
underlying MemBlob buffer while we are appending things to the
accumulation SBuf. The preservation of the underlying MemBlob buffer is
what makes all the append-after-copy operations efficient.

> If there is any case that is hard as Titanium I will be more then glad
> to read and understand it.

If I knew of any specific use cases, I would call for a redesign. I do
not think such cases exist in the current code. Moreover, I cannot think
of a realistic scenario that will create them in the future. Thus (and
since it is not me doing the coding), I do not think a redesign using
for_each() or some such is necessary (even though it would not be that
difficult). Perhaps I should not have even documented my "feelings"
regarding optimization fragility of my sketched approach.

Cheers,

Alex.
Received on Tue Dec 03 2013 - 00:23:54 MST