[Mono-dev] PATCH: Make Process.Start() use thesame'mono'runtime

[Jonathan Gilbert]

At 05:18 PM 6/6/2007 -0400, Miguel de Icaza wrote:
>Hey,
>
>> I just ran a performance test. The unmanaged implementation adds about 1
>> second for every 100,000 child processes. Even the managed version, which
>> is, as expected, a lot slower, it adds less than 5 seconds for every 10,000
>> child processes. In what situation would this be a severe and noticeable
>> penalty? Surely the overhead of actually setting up a 10,000 child
>> processes totally eclipses a 5 second penalty.
>
>I went with your unmanaged code patch, so we are going with 1 instead of
>5 ;-)

Actually 0.1 instead of 5. It really is a lot faster because it has a lot
less to do and even when it's doing the same thing it's so much more direct
than the FileStream class. At the same time, though, it doesn't fix the
problem on Windows. If I write an app that expects a child process to be
able to connect back to the parent with .NET Remoting, there's a good
chance users'll run into problems if they choose to run it with mono on
Windows. If Microsoft's framework isn't installed, it won't work *at all*;
if Microsoft's framework is installed, there could still be serious
problems with remoting incompatibilities (wasn't there just recently an
e-mail about remoting compatibility for
System.Collections.Generics.Dictionary`2?).

I wonder -- is there any possibility of supporting Windows and making the
(extremely minor in my opinion, but still much larger than with pure
unmanaged code) performance hit a Windows-only thing with something like
#if WIN32? Or is the managed part of the BCL designed to be buildable on
any platform and subsequently used on any other with no changes? I suppose
if Windows users complain about it, it could in the end be done with an
icall which is #ifdef WIN32'd on the C side... Heck, could even check
Environment.OSVersion.Platform (or use whatever better way there may be
available within the BCL for detecting the platform) and disable the
managed check that way. Presumably the overhead on that bitwise test would
be significantly less than actually opening the file and peeking at the
first few kilobytes. :-)

I'm sorry I just won't let this die, but it really feels like only half the
problem is solved because the problem isn't addressed for one of the
platforms mono supports.

>Thanks a *lot* for the patch, every couple of weeks I would think
>"Jesus, how come we have not implemented this" and for one reason or
>another never got around to it.

It was fun writing it :-)

Thanks,

Jonathan Gilbert