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
