On Fri, 12 Apr 2013 06:14:35 -0400, Regan Heath <re...@netmail.co.nz>
wrote:
On Fri, 12 Apr 2013 10:17:54 +0100, Vladimir Panteleev
<vladi...@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
