On Friday, 12 April 2013 at 11:37:14 UTC, Regan Heath wrote:
I've moved this to another thread to allay complaints.

Thanks!

I completely agree that if code can be made more performant without a significant increase in complexity, then we should do so. While it is mostly (but not entirely) irrelevant in the context of std.process, it is a problem that should be tackled in Phobos as a whole. Several things could/should be done:

It would be nice to have some sugar on top of alloca(), the use of which is usually considered bad practice. Someone (bearophile?) once suggested static arrays whose length is determined at runtime, which would be a great addition to the language:

    void foo(int n)
    {
        int[n] myArr;
        ...
    }

Furthermore, we need to get the allocator design in place. In SciD, I use David Simcha's region allocator to allocate temporary workspace, and it works really well. The only times I use 'new' is when I need persistent memory (e.g. for a return value) and the user-supplied buffer is too small. Phobos would greatly benefit from doing this too.

Finally, an example from the new std.process which got some heavy criticism in the other thread:

    envz[pos++] = (var~'='~val~'\0').ptr;

I have been operating under the assumption that the compiler is smart enough to make the above a single allocation. If it isn't, I would consider it a compiler issue.

That said, I am aware that std.process could be improved in some places.

Lars

Reply via email to