Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mass spawning of processes slower than with mono #25879

Closed
myrup opened this issue Apr 12, 2018 · 6 comments
Closed

Mass spawning of processes slower than with mono #25879

myrup opened this issue Apr 12, 2018 · 6 comments
Labels
area-System.Diagnostics.Process enhancement Product code improvement that does NOT require public API changes/additions tenet-performance Performance related issue
Milestone

Comments

@myrup
Copy link

myrup commented Apr 12, 2018

Continuing discussion from dotnet/corefx#26291 :

I know it's in the enhancement department, but since I felt a significant difference testing mono and .Net Core I decided to time it.

The following snip takes 15s vs 10s in .Net Core 2.1 preview 2 vs. mono 5.8.1 :

var stopwatch = Stopwatch.StartNew();
for (int i = 0; i < 10000; i++)
        Process.Start("echo", i.ToString());
Console.WriteLine("Took " + stopwatch.Elapsed);

33% slower launch times for processes seems significant to me.

(I'm on Darwin. You know best if this concerns all *nix)

[EDIT] Add C# syntax highlighting by @karelz

@karelz
Copy link
Member

karelz commented Apr 12, 2018

@myrup did you try to profile it to see where is the difference?

@tmds
Copy link
Member

tmds commented Apr 12, 2018

These processes are short lived. This is both mass spawning and mass exiting happens concurrently. Both mono and corefx have a lock that protects the list of running children during spawn and exit. Corefx lock includes the fork system call and mono does not. This makes mono perform better, but there is a race where the process may exit before it is added to the list.

@karelz
Copy link
Member

karelz commented Apr 12, 2018

So it is accuracy vs. perf.
What is the proposal then? Given up on accuracy as Mono, or beef it up and hope we keep the perf wins?

@tmds
Copy link
Member

tmds commented Apr 12, 2018

I don't think this represents a common scenario. It's a worst case benchmark. So let's keep it accurate.

@karelz
Copy link
Member

karelz commented Apr 12, 2018

I agree that accuracy in this case should be preferred, given it is not mainstream scenario. I suggest to close the issue as By Design. Any thoughts / push back @myrup?

@myrup
Copy link
Author

myrup commented Apr 12, 2018

I created a snip to separate timing of launches from exits. The code times launches for 10000 processes and ignores exit times:

var stopwatch = Stopwatch.StartNew();
var n = 1000; // Maximum amount of processes running at a time
for (int j = 0; j < 10; j++) { // do chunks of launches
        for (int i = 0; i < n; i++) {
                Process.Start("sleep", "2"); // it takes about a second to launch n processes
                Console.WriteLine(j * n + i);
        }
        stopwatch.Stop();
        Thread.Sleep(3000); // wait for n processes to exit
        stopwatch.Start();
}
Console.WriteLine("Took" + stopwatch.Elapsed); // 10000 processes

It takes about 12s vs 13s (.Net Core vs mono) ; .Net Core is actually slightly faster than mono. The faster total for mono could be attributed to processes not being reaped. Definitely go with accuracy.

Good job @tmds!

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 2.1.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Diagnostics.Process enhancement Product code improvement that does NOT require public API changes/additions tenet-performance Performance related issue
Projects
None yet
Development

No branches or pull requests

5 participants