toString refactor in druntime

[Walter Bright via Digitalmars-d]

On 11/2/2014 3:57 PM, Dicebot wrote:
> 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.

I still have no idea how this would apply here.


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

There is no problem with having the max stack allocation for scopebuffer use set 
smaller for 32 bit code than 64 bit code.


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

What part of druntime would be special case for servers?


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

Minimizing allocations is about dealing with the most common cases.


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

It's not that hard.


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

The point is what to do when the array gets full.