<div dir="ltr">On 12 April 2013 23:32, 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 12:52:39 UTC, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If it's somehow hard to put a string on the stack, then there may be a hole<br>
in phobos. I'm not suggesting changes that are somehow hard to implement,<br>
or obscure in some way... they should be utterly trivial.<br>
</blockquote>
<br></div>
Well, ironically or not, it is not something utterly trivial.<br>
<br>
The main issue is that the stack can't hold a lot of data. This is not a problem with the heap, which is limited by the amount of memory and address space; these (usually abundant) limits are usually the user's concern, not the programmer's.<br>

<br>
Did you know that Linux does not impose a limit on the size of the environment? The default stack size seems to be 8MB... Now, what would happen if on certain machines that, for one reason or another, have an environment larger than that, and std.process did not account for it?<br>

<br>
So, to perform the task correctly, std.process would need to perform most allocations on the stack if they are up to a certain size, and on the heap otherwise.<br>
<br>
What would be a good limit for stack allocations? You may want to choose a value based on whatever's the default stack size on today's Linux versions (after all, std.process is near the "leaf" parts of call stacks). However, certain applications create a lot of stacks, for example for use in lightweight threads (fibers). When restricted by a small address space (32-bit architecture), the stacks need to be much smaller than usual...</blockquote>
<div><br></div><div style>Yes, you're right, there's an 'if' required here to catch unreasonably large environment blocks, but I still consider that within the realm of 'trivial'.</div><div style>This is processed in an appending loop, just check the next bit fits, and if it overflows 1kb or so of stack string, revert to the heap and continue.</div>
<div style><br></div><div style>I reckon helpers could be written to assist with common cases of this (which would have to be mixin template based I guess?)...</div><div style>And I really like the variable-length static array idea!</div>
<div style><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">
I highlighted, and suggested trivial changes that<br>
would make a big difference and don't hurt anyone.<br>
</blockquote>
<br></div>
Well, why do you think they would make a big difference in std.process?<br>
<br>
I don't think any of the Phobos developers are against improving performance when the cost is low. So, it's not that I think you're wrong in general, but that the std.process scapegoat (for lack of better word) was not the best choice.<br>
</blockquote><div><br></div><div style>Fuck, I've repeated myself so many times now. The point I make is a general issue I have with phobos, I consider it an issue that should be made policy (irrespective of module being considered), and std.process came into question right at the moment I thought to make the point. It may not be the strongest case for the principle, it's just the one that appeared.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suggest that you file enhancement requests on Bugzilla for each specific component of Phobos / Druntime, improving the allocation behavior of which would result in a real-world benefit for you.<br>
</blockquote></div><br></div><div class="gmail_extra" style>I'll start doing it myself, but I also suggest it be made a policy, and carefully considered when considering acceptance of ANY new module. That way, new code that suffers the unpredictable/"surprise!" allocation problems won't be introduced.</div>
</div>