On Friday, 12 April 2013 at 12:52:39 UTC, Manu wrote:
If it's somehow hard to put a string on the stack, then there
may be a hole
in phobos. I'm not suggesting changes that are somehow hard to
implement,
or obscure in some way... they should be utterly trivial.
Well, ironically or not, it is not something utterly trivial.
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.
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?
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.
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...
I highlighted, and suggested trivial changes that
would make a big difference and don't hurt anyone.
Well, why do you think they would make a big difference in
std.process?
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.
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.
