buffered input

spir denis.spir at gmail.com
Sun Feb 6 09:42:27 PST 2011


On 02/06/2011 04:25 PM, Andrei Alexandrescu wrote:
> Say the buffer has 1000 elements of which the last 100 contain data (and the
> other 900 are past data that's not used). Then say this request comes:
>
> stream.appendToFront(150);
>
> At this point the stream may go two ways:
>
> 1. Append to the internal in-memory buffer, making it larger:
>
> _buf.length += 150;
> ... read into _buf[$ - 150 .. $] ...
>
> Now we have a buffer that has 1100 elements, of which the last 250 are used.
>
> 2. Move the data to the beginning of the buffer and then read 150 more elements
> starting at position 100:
>
> _buf[0 .. 100] = _buf[$ - 100 .. $];
> ... read into _buf[100 .. 250] ...
>
> Now _buf has still 1000 elements, of which the first 250 contain data.
>
> How does the stream decide between 1 and 2? Clearly it's undesirable to grow
> the buffer too much and it's also undesirable to copy too much data. A simple
> approach is to establish a bound on losses, for example copy data only if size
> to copy is < 5% of the entire buffer.

Isn't absolute size also relevant, if not more? I mean, as long as buffer size 
is small (if not insignificant) in absolute value, compared to eg CPU cache or 
available RAM, may it be good strategy to grow it whatever the relative growth 
in proportion of current size?

Also: could a (truely) circular buffer help & solve the above copy problem, 
concretely?


Denis
-- 
_________________
vita es estrany
spir.wikidot.com



More information about the Digitalmars-d mailing list