Phobos for Review: std.buffer.scopebuffer

[Paulo Pinto]

Am 08.02.2014 02:30, schrieb 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
>

There quite a few Java libraries that follow this pattern.

--
Paulo