toString refactor in druntime

Walter Bright via Digitalmars-d digitalmars-d at puremagic.com
Sat Nov 1 10:50:29 PDT 2014


On 11/1/2014 5:31 AM, Dicebot wrote:
> On Saturday, 1 November 2014 at 07:02:03 UTC, Walter Bright wrote:
>> On 10/30/2014 8:30 AM, Steven Schveighoffer wrote:
>>> This is a typical mechanism that Tango used -- pass in a ref to a dynamic array
>>> referencing a stack buffer. If it needed to grow, just update the length, and it
>>> moves to the heap. In most cases, the stack buffer is enough. But the idea is to
>>> try and minimize the GC allocations, which are performance killers on the
>>> current platforms.
>>
>> We keep solving the same problem over and over. std.internal.scopebuffer does
>> this handily. It's what it was designed for - it works, it's fast, and it
>> virtually eliminates the need for heap allocations. Best of all, it's an
>> Output Range, meaning it fits in with the range design of Phobos.
>
> It is not the same thing as ref/out buffer argument.

Don't understand your comment.


> We have been running
> ping-pong comments about it for a several times now. All
> std.internal.scopebuffer does is reducing heap allocation count at cost of stack
> consumption (and switching to raw malloc for heap) - it does not change big-O
> estimate of heap allocations unless it is used as a buffer argument - at which
> point it is no better than plain array.

1. stack allocation is not much of an issue here because these routines in 
druntime are not recursive, and there's plenty of stack available for what 
druntime is using toString for.

2. "All it does" is an inadequate summary. Most of the time it completely 
eliminates the need for allocations. This is a BIG deal, and the source of much 
of the speed of Warp. The cases where it does fall back to heap allocation do 
not leave GC memory around.

3. There is big-O in worst case, which is very unlikely, and big-O in 99% of the 
cases, which for scopebuffer is O(1).

4. You're discounting the API of scopebuffer which is usable as an output range, 
fitting it right in with Phobos' pipeline design.

Furthermore, again, I know it works and is fast.


More information about the Digitalmars-d mailing list