On 12 April 2013 23:08, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:
On Friday, 12 April 2013 at 11:37:14 UTC, Regan Heath wrote:
It very much matters *who* that 1 user is.  And, the count may be higher, and we might never "hear" from these people as they find other solutions.  We're lucky that some people who try D and have issues tell us about them, they may be 5% of the total for all we know.

The same applies to the other side of the argument. A buggy standard library probably leaves a worse impression than a slow standard library...

If allocating a string on the stack makes it buggy, then there is something really wrong. It should be no less convenient if appropriate helpers are available.
With consideration to the string[string] argument, surely instances like that can be reconsidered? How is string[] going to produce more bugs than string[string]?
You're being paranoid, or sensationalising the effect of simple optimisation.

In reality the suggested improvements would add only very minor complexity and prevent none of the current crop of contributors from working with/on std.process.

Well, how do you qualify the amount of optimization that is appropriate?

As much is convenient without causing you to start obscuring your code? That's my personal rule.
But I make it a habit to consider efficiency when designing code, I never retrofit it. I tend to choose designs that are both simple and efficient at the start.

For example, the code in std.process would be even faster, if it was completely written in assembler. I hope we'll agree than in practice, this would be absurd. Now, what set of well-defined arguments would conclude that rewriting it in assembler is pointless, but optimizing memory allocations is not? All three versions of std.process would perform as well as far as the end-user can perceive.

Actually, it would probably be slower if hand-written in assembler. And again, speed is not my concern here, it's inconsiderate the allocation policy.

Yes, as well as the users of their applications.  True, none of them will even realise they could have been less happy, so none of them will realise the effort that went into it, but all of them will be better off.

Absolutely - if you ignore the costs. 100%-correct faster code is always better than 100%-correct slower code, but the costs are the counter-argument.

Can you describe the 'costs'?

Add the missing items, without a doubt - which is why no-one is suggesting blocking std.process over this issue.

Blocking is one thing, but asking for faster code where it doesn't really matter - when there are areas where D could be improved at much higher gain per effort - is another.

I'm asking for code that doesn't needlessly allocate, as a policy/habit in phobos.

D is a systems programming language, there is hope that it
Why?


There exist platforms and environments where memory and performance are concerns, if the D standard library code is not "careful" in it's use of both then it will be less suitable than C (for example) and so D will not penetrate those platforms.

OK, but once again - how does that line up with the purpose of std.process? I can see how std.algorithm can be useful in low-spec embedded/gaming systems, but std.process?


Manu is using D for games development on modern high-end gaming PCs and he is still concerned with memory and performance.

In Manu's case, every bit of performance counts in the code that runs in tight loops, e.g. for every game frame. However, does that include std.process?

I'm interested in eliminating allocations. It's just another function that can't be called in a no-gc area. If it used the stack for its temporaries, no problem.

All true, but performance is one of D's top draw cards:

<quote>The D programming language. Modern convenience. Modeling power. Native **efficiency**.</quote> (**emphasis mine**)

So, it behoves us to make sure the standard library keeps that in mind.

Again, I don't (generally) disagree for the general case, however I think it pays to mind the context and perspective. When the context is std.process and the perspective is the relative cost of process creation, it seems like quite a pointless argument.

It was the first module that appeared for consideration since the recent discussions about irresponsible GC usage. The argument applies to everything considered for acceptance into phobos.
I'd like to see it applied as a systematic consideration in the future, irrespective of the module being considered. Avoiding allocation for temporaries shouldn't be hard, if some tools are missing, then that is something that needs further discussion I guess.