Phobos for Review: std.buffer.scopebuffer

[Jonathan M Davis]

On Friday, February 07, 2014 11:23:30 Lars T. Kyllingstad wrote:
> 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.

We really should be moving to a model where any function that returns a new 
array has on overload which takes an output range and uses that for the output 
instead of returning a newly allocated array. That way, code that doesn't need 
the performance boost can just use the return value like we do now, but more 
performance-critical code can use output ranges and avoid GC allocations and 
the like.

- Jonathan M Davis