On 2/7/2014 2:27 AM, dennis luehring wrote:
> Am 07.02.2014 10:13, schrieb Walter Bright:
>> 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.
>
> did you also test the codegen of ldc and gdc - or is this optimization
> only "working" for dmd?

It's part of the C ABI.

Do you want this to included into review queue for formal voting?

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.
>
> ScopeBuffer is an OutputRange that sits on the stack, and overflows to malloc/free. It's designed to help in eliminating gc allocation by lower level functions that return buffers, such as std.path.buildPath(). With some judicious user tuning of the initial stack size, it can virtually eliminate storage allocation.
>
> Using it is @system, but the user of ScopeBuffer can be @trusted.
>
> An output range like this is a precursor to eliminating the excessive gc use by functions such as buildPath().

Wasn't there a simple composed Allocator from std.allocator that did exactly this? Composing InSituAllocator with Mallocator through FallbackAllocator or something.

On 2/7/2014 3:00 AM, Dicebot wrote:
> Do you want this to included into review queue for formal voting?

Sure.

On 2/7/2014 3:05 AM, Jakob Ovrum wrote:
> Wasn't there a simple composed Allocator from std.allocator that did exactly
> this? Composing InSituAllocator with Mallocator through FallbackAllocator or
> something.

I don't know anything about that.

On Friday, 7 February 2014 at 10:29:07 UTC, Walter Bright wrote:
> On 2/7/2014 2:02 AM, Lars T. Kyllingstad wrote:
>> I don't understand.  Even if your workspace is stack-based or malloc-ed, you
>> still need that one GC allocation for the return value, no?
>
> If you have a path with 20 entries in it, and don't find the file, you do zero allocations instead of 20. If you find the file, that's do one allocation instead of 20/2 (on average), and you might be able to avoid that by passing it upwards, too :-)

Ah, now I understand.  I misunderstood you -- I thought you meant that using ScopeBuffer to build the return array inside buildPath(), while retaining the function's API, would somehow improve its performance greatly.  But what you're saying is that you would change the signature as well, to something like this:

  void buildPath(IR, OR)(IR segments, OR result)
      if (isInputRange!IR && isOutputRange!(OR, char));

I fully agree, then, and I see how ScopeBuffer would be extremely useful if more of Phobos' functions were written like this.  In the specific case of buildPath(), I've actually considered letting the user supply their own buffer in the form of an array, but this is of course a more general solution.

On Friday, 7 February 2014 at 11:05:08 UTC, Jakob Ovrum wrote:
> Wasn't there a simple composed Allocator from std.allocator that did exactly this? Composing InSituAllocator with Mallocator through FallbackAllocator or something.

Yes, looks very similar. I'd like to preserve ScopeBuffer output range API but express it internally in terms of std.allocator - will also be good field test for performance of the latter.

On Friday, 7 February 2014 at 11:23:31 UTC, Lars T. Kyllingstad wrote:
> But what you're saying is that you would change the signature as well, to something like this:

See my output range thread too: we might be able to still return the slice while taking the OR for result, and also through in a default value so things just work without changes.

Some caution would be needed by the caller to understand that if you pass a scope buffer as the output range, the returned slice is owned by that buffer too... but that's a managable restriction, they did pass the buffer after all so it is no surprise to them when it gets used!

On 2/7/2014 7:57 AM, Adam D. Ruppe wrote:
> Some caution would be needed by the caller to understand that if you pass a
> scope buffer as the output range, the returned slice is owned by that buffer
> too... but that's a managable restriction, they did pass the buffer after all so
> it is no surprise to them when it gets used!

That's why the [ ] overloads are marked @system.

On 2014-02-07 09:24, 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.
>
> ScopeBuffer is an OutputRange that sits on the stack, and overflows to
> malloc/free. It's designed to help in eliminating gc allocation by lower
> level functions that return buffers, such as std.path.buildPath(). With
> some judicious user tuning of the initial stack size, it can virtually
> eliminate storage allocation.
>
> Using it is @system, but the user of ScopeBuffer can be @trusted.
>
> An output range like this is a precursor to eliminating the excessive gc
> use by functions such as buildPath().

Since this is a completely new module, even new package, this should go through the standard review process. That means:

* Add to review queue
* Generate documentation
* Do not create a pull request until the review is complete and the module has been approved. This easy to to a comparison with Github without having to create a pull request

-- 
/Jacob Carlborg