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.
