Lots of low hanging fruit in Phobos

[Walter Bright]

On 3/6/2014 5:54 PM, Jakob Ovrum wrote:
> While I prefer this approach most of the time, I fear it has a performance cost
> over sink-style algorithms (whether they use an output range or build an array
> result). I guess the question is whether this cost is generally offset by gains
> in the memory allocation code or not.

std.buffer.scopebuffer was developed for that purpose, and as the discussion on 
why it is the way it is shows, it was developed with extensive use of a profiler 
to ensure there was no speed compromise from using it.


>> For example, we could implement toStringz() as an algorithm that looks like:
>>
>>     auto toStringz(S)(S s) {
>>         return chain(s, repeat(0, 1))
>>     }
>
> std.range.only is more suitable than `repeat` here

Yes, I missed that. I'm still learning about the proper way to use ranges.


> (and I don't know if `chain`
> would let you chain a range of characters with a range of integers):

My code fragment is untested and pretty much off the cuff. A real version would 
be a bit more complex, as you suggest.


> Either way, perhaps the most serious problem is that when using `copy` to write
> the result to an array, both UTF decoding and re-encoding takes place (the
> result is always a range of `dchar`).

I know. I struggled with that myself, and I object to the design decision that 
auto-decodes and auto-encodes any ranges that deal with char's. It automatically 
turns fast code into molasses. I wound up casting everything to ubytes, ugh.

But it's too late to change that now, sigh.