On Fri, 12 Apr 2013 03:04:08 -0400, Manu <turkey...@gmail.com> wrote:
On 12 April 2013 14:46, Jesse Phillips <jessekphillip...@gmail.com>
wrote:
It is that time, If you would like to see the proposed std.process
include
into Phobos please vote yes. If one condition must be met specify under
what condition, otherwise vote no.
I didn't think I had much of an opinion on std.process, but I just gave
it
a quick once over and noticed, relating to our recent discussions about
flagrant GC usage throughout phobos, that this is riddled with the exact
sorts of issues I've been talking about:
It's spawning a new process. What is the issue with allocating a bit of
memory? The spawning of the process performance is going to dwarf that of
any memory allocations.
string[string] is used in the main API to receive environment variables;
perhaps kinda convenient, but it's impossible to supply environment
variables with loads of allocations.
I think you meant "without"?
What would be your suggestion? string[string] is the built-in map type.
How do you pass an environment map without having some allocations?
toStringz is used liberally; alternatively, alloca() could allocate the
c-string's on the stack and zero terminate them there, passing a pointer
to
the stack string to the OS functions.
This would be a lot of effort for pretty much zero gain for the majority
of cases.
String concatenation is rampant! Look at this code to parse the env
variables (which are already an AA):
foreach (var, val; childEnv)
envz[pos++] = (var~'='~val~'\0').ptr;
This could be improved. It could also be optimized into a single
allocation automatically by the compiler (it might already be). The API
would not be affected by this improvement, though.
And many many more of the same...
This is a lib that spawns a process, I can't imagine why this library
should need to allocate a single byte, but it allocates wildly just to
perform a trivial pass-through to the OS.
It is not a trivial pass-through. Different OSes require different
parameter types. Look at the difference between the windows and posix
implementations. We are writing a cross-platform library, so whatever we
pick will have to be converted on at least one OS.
This module is no exception either, basically all of phobos is like this,
and I'd like to see careful consideration made to these details in the
future.
I too like to avoid memory allocations. But the level to which you
require is too stringent. Not even Tango, which made low heap-allocations
a priority, avoided allocations in it's process library.
I've said before, I sadly have to avoid phobos like the plague. Some
modules (like this one) that provide fundamental functionality - not just
helper functions - can't be avoided. Requirements for those should be
extra
strict in my opinion.
We cannot cater to all developers. To put all developers through a lot of
pain in order to attract the fringe ones is not a practical goal.
I think the convenience of std.process is what it is there for. For the
highest performance, you are able to call the OS functions directly.
-Steve
