Phobos for Review: std.buffer.scopebuffer

Walter Bright newshound2 at digitalmars.com
Fri Feb 7 01:13:14 PST 2014


On 2/7/2014 12:46 AM, Brad Anderson wrote:
> On Friday, 7 February 2014 at 08:24:39 UTC, Walter Bright wrote:
>> https://github.com/D-Programming-Language/phobos/pull/1911
>>
>> This adds a package std.buffer, and the first entry in that package,
>> std.buffer.scopebuffer.
>
> About to go to bed so just a couple of quick thoughts.
>
> Why not just stick the stack array in ScopeBuffer itself (the
> size could be a template parameter)?

1. It's set up to fit into two registers on 64 bit code. This means it can be 
passed/returned from functions in registers. When I used this in my own code, 
high speed was the top priority, and this made a difference.

2. It needs to avoid the default initialization of the array, because it's both
unnecessary and it kills the speed. Currently, this
cannot be avoided for part of a struct.

3. I wanted it to be usable for any block of memory the user wished to dedicate 
to be a buffer.

4. Having an internal reference like that would mean a postblit is required for 
copying/moving the range, another source of speed degradation.


The design of ScopeBuffer is based on a fair amount of trial and error on my 
part trying to wring as much speed as possible out of it.


> Also, if it did embed the static array in the ScopeBuffer I
> wonder if it could just use the pointer as the buffer if the
> length is less than size_t (short string optimization).

I almost never needed a buffer that small, and the extra tests for it killed 
performance (I had tried it at one point).


> (Just thinking aloud, I wonder if std.allocators could be used to
> implement this more generically (hypothetically: alias
> ScopeBuffer =
> CustomAllocOutputRange!(StaticWithMallocFallbackAllocator!10)))

The custom allocator design is a long way from being realized. I don't know if 
it would help or not.


> It's a welcome addition and will go a long way toward cutting
> down GC allocations once Phobos is output-range-ified. This technique is
> probably the first thing I'd reach for when choosing an output range.

Once the buffer package is accepted, I want to add others I've been using like 
circular buffers (the one from the compressor proposal), fixed buffers, and even 
move std.outbuffer to it. I also want it to be one buffer design per module, not 
the usual grab-bag modules.



More information about the Digitalmars-d mailing list