toString refactor in druntime

[Dicebot via Digitalmars-d]

On Saturday, 1 November 2014 at 17:50:33 UTC, Walter Bright wrote:
>> It is not the same thing as ref/out buffer argument.
>
> Don't understand your comment.

Steven comment has mentioned two things about Tango approach - 
using stack buffer as initial buffer and extensive usage of ref 
parameters for such arguments. std.internal.scopebuffer on its 
own only addresses the former.

>> 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.

Fibers.

Ironically one more problematic parts of Tango for us is the 
Layout one which uses somewhat big stack buffer for formatting 
the arguments into string. It is a very common reason for fiber 
stack overflows (and thus segfaults) unless default size is 
changed.

With 64-bit systems and lazy stack page allocation it is not a 
critical problem anymore but it is still important problem 
because any growth of effective fiber stack prevents one from 
using it as truly cheap context abstraction.

Persistent thread-local heap buffer that gets reused by many 
bound fibers can be much better in that regard.

> 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.

We have a very different applications in mind. Warp is "normal" 
single user application and I am speaking about servers. Those 
have very different performance profiles and requirements, 
successful experience in one domain is simply irrelevant to other.

> 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).

And with servers you need to always consider worst case as 
default or meet the DoS attack. I am not even sure where 99% 
comes from because input length is usually defined by application 
domain and stack usage of scopebuffer is set inside library code.

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

Any array is output range :)