Vote for std.process

[Regan Heath]

On Fri, 12 Apr 2013 09:38:53 +0100, Vladimir Panteleev  
<vladimir at thecybershadow.net> wrote:

> On Friday, 12 April 2013 at 08:26:48 UTC, Manu wrote:
>> Again, I'm just suggesting possibilities, and trying to illustrate that
>> it's a STANDARD library, you can never predict where users will want to  
>> use
>> it.
>
> So you are talking about an imaginary system where memory allocation is  
> expensive but process creation is cheap.
>
> It's impossible to design and optimize software for some intangible  
> goals. None of the systems that D targets, or aims to target, meet that  
> criteria.

I don't understand why you're so "against" these comments.  There is no  
real "argument" here, you both want std.process to be as good as it can be  
and it will clearly be better if it performs faster and allocates less.

Yes, premature optimisation is generally frowned upon in "user" code, but  
library code should ideally be optimised.  Should this percieved lack of  
optimisation prevent it's inclusion now, no because optimisation wont  
change the API (it may extend it however).

>> Can you perhaps quantify how any of those things would be reduced by
>> addressing at least the details I highlight?
>> I'm basically advocating making a habit of using the stack where  
>> possible.
>> It's not exactly hard, or cryptic.
>
> Yes. However, I suggest the following instead:
>
> Please rewrite some part of std.process with performance in mind, and  
> post it here for review. This way, we can analyze the benefits and  
> drawbacks based on a concrete example, instead of vapor and hot air.

Fair point, after all someone has to do the work and it seems logical that  
the person with the most understand of the issue should so it.  Whether he  
has the time however is the Q/problem.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/