Vote for std.process

[Steven Schveighoffer]

On Fri, 12 Apr 2013 06:14:35 -0400, Regan Heath <regan at netmail.co.nz>  
wrote:

> On Fri, 12 Apr 2013 10:17:54 +0100, Vladimir Panteleev  
> <vladimir at thecybershadow.net> wrote:

>> Optimizing code often implies making it more complicated.
>>
>> Straight-forward code is self-documenting.
>>
>> More complicated code is harder to read and review.
>>
>> More complicated code more easily hides bugs - including security bugs,  
>> such as buffer overflows.
>>
>> Maintaining optimized code requires understanding not only the  
>> high-level logic, but also the low-level optimization details.
>>
>> The benefits of optimizing std.process are likely to be so small, as to  
>> be difficult to measure.
>
> All true.  However, complexity can and should be packaged in such a way  
> as to localise, and this localised complex code should be tested to  
> death and maintained by someone who understands it.  It should be  
> bracketed by sufficient comments and warnings about how/why it does what  
> it does.  The resulting packaged complexity, with it's associated cost  
> can be re-used many times over for all the benefit it gives.

I would say I agree with both of you.  In this particular instance,  
maintainability trumps performance, since creating processes is  
fundamentally not cheap.  But if someone is willing to step up an give us  
a good alternative, there is no reason not to use it.  It should be  
readable and well documented.

I think in order to achieve good performance, we should be focused on  
custom allocators.  That really is the roadblock to all of this.

-Steve