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
