<div dir="ltr">On 12 April 2013 23:08, Vladimir Panteleev <span dir="ltr"><<a href="mailto:vladimir@thecybershadow.net" target="_blank">vladimir@thecybershadow.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Friday, 12 April 2013 at 11:37:14 UTC, Regan Heath wrote:<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
</blockquote></div><div class="im">
<br></div>
The same applies to the other side of the argument. A buggy standard library probably leaves a worse impression than a slow standard library...</blockquote><div><br></div><div style>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.</div>
<div style>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]?</div><div style>You're being paranoid, or sensationalising the effect of simple optimisation.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
Well, how do you qualify the amount of optimization that is appropriate?<br></blockquote><div><br></div><div style>As much is convenient without causing you to start obscuring your code? That's my personal rule.</div>
<div style>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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.</blockquote>
<div><br></div><div style>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote>
<br></div>
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.</blockquote><div><br></div><div style>Can you describe the 'costs'?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Add the missing items, without a doubt - which is why no-one is suggesting blocking std.process over this issue.<br>
</blockquote>
<br></div>
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.<br></blockquote><div><br></div><div style>
I'm asking for code that doesn't needlessly allocate, as a policy/habit in phobos.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
D is a systems programming language, there is hope that it<br>
</blockquote></blockquote></div>
Why?<div class="im"><br>
<br>
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.<br>

</div></blockquote>
<br>
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?<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Manu is using D for games development on modern high-end gaming PCs and he is still concerned with memory and performance.<br>
</blockquote>
<br></div>
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?</blockquote><div><br></div><div style>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
All true, but performance is one of D's top draw cards:<br>
<br>
<quote>The D programming language. Modern convenience. Modeling power. Native **efficiency**.</quote> (**emphasis mine**)<br>
<br>
So, it behoves us to make sure the standard library keeps that in mind.<br>
</blockquote>
<br></div>
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.<br>

</blockquote></div><br></div><div class="gmail_extra" style>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.</div>
<div class="gmail_extra" style>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.</div>
</div>