Garbage collection, and practical strategies to avoid allocation

[Jonathan M Davis]

On Saturday, June 01, 2013 04:47:39 Brad Anderson wrote:
> I played around with adding an overload that accepted an output
> range to some of the std.string functions identified in my run of
> -vgc over phobos[1] (after Jonathan pointed out this is probably
> the best approach and is already what formattedWrite does).  It
> worked fine but it did make me realize there aren't a lot of
> output ranges available to plug in at the moment (appender and
> lockingTextWriter are the only two that come to mind though there
> may be others).  Appender isn't useful if your goal is to avoid
> the GC.  Array!char et al aren't output ranges (whether they
> should be or not I have no idea).  static arrays would need some
> sort of wrapper to make them output ranges I believe unless it
> was decided that put() should work by replacing the front and
> calling popFront for them (which I kind of doubt is the desired
> behavior).
> 
> (feel free to correct me on any of this, range experts)
> 
> 1. http://goo.gl/HP78r

Dynamic arrays are output ranges. The one potential hitch there though relates 
to the fact that they get written to rather than appended to. This is actually 
exactly what you want in a situation like Manu's. However, that means that you 
have to worry about an output range running out of space and how you deal with 
that.

If it's know how much will need to be appended, presumably you can check 
length if hasLength!R is true. Otherwise, I guess that the right thing to do 
is to check empty (arrays get shrunk as they're written to, so they'll be 
empty when you can't call put on them anymore). Unfortunately, put doesn't 
seem to worry about the case where the ouput range is full/empty, so the 
result when calling put on an empty range is undefined. The situation is even 
worse with narrow strings (assuming that put works with them - I'm not sure 
that it does at the moment) given that even if you knew their length (which 
you wouldn't if you were going by hasLength), you wouldn't know whether a put 
would succeed when the string was nearly empty, as the actual number of 
elements that the dchar would take up would depend on its value.

In general, I don't think that output ranges have really been sorted out on 
quite the level that input ranges have been, and I think that some discussion 
is in order with regards to how to handle things like when the range can't be 
put into anymore. Given that one reason to use output ranges is for 
performance-critical code that doesn't want to allocate, throwing when the 
range is empty is probably a bad idea, and it's unclear that we can reasonably 
determine in the general case whether you can put to an output range before 
you actually try it. One solution to that would be to make bool return whether 
it succeeded or not, but it's an issue that definitely needs to be explored a 
bit.

So, I very much think that the correct thing is to use output ranges, but how 
to use them needs to be better defined, and we probably need to better sort out 
some of their details (like the finish function which the hash stuff uses).

- Jonathan M Davis