runtime: Performance regression: Process.GetCurrentProcess().Dispose() on Windows

It looks like Process.GetCurrentProcess() have regressed on Windows.

git clone https://github.com/dotnet/performance.git
cd performance
# if you don't have cli installed and want python script to download the latest cli for you
py .\scripts\benchmarks_ci.py -f netcoreapp2.2 netcoreapp3.0 --filter System.Diagnostics.Perf_Process.GetCurrentProcess
# if you do
dotnet run -p .\src\benchmarks\micro\MicroBenchmarks.csproj -c Release -f netcoreapp2.2 --runtimes netcoreapp2.2 netcoreapp3.0 --filter System.Diagnostics.Perf_Process.GetCurrentProcess

It’s also suprising that the method is 4 times slower on Ubuntu 18 compared to Ubuntu 16.

System.Diagnostics.Perf_Process.GetCurrentProcess

conclusion	Base	Diff	Base/Diff	Operating System	Arch	Processor Name	Base Runtime	Diff Runtime
Same	445.90	459.75	0.97	ubuntu 18.04	64bit	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 2.2.6	.NET Core 3.0.0-preview8-27919-09
Slower	85.47	105.94	0.81	Windows 10.0.18362	64bit	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 2.2.6	.NET Core 3.0.0-preview8-27919-09
Slower	165.85	202.40	0.82	ubuntu 16.04	64bit	Intel Xeon CPU E5-2673 v4 2.30GHz	.NET Core 2.2.6	.NET Core 3.0.0-preview8-27919-01
Same	792.90	812.41	0.98	ubuntu 18.04	64bit	Intel Xeon CPU E5-2673 v4 2.30GHz	.NET Core 2.2.6	.NET Core 3.0.0-preview8-27919-01
Slower	119.86	130.78	0.92	macOS Mojave 10.14.5	64bit	Intel Core i7-5557U CPU 3.10GHz (Broadwell)	.NET Core 2.2.6	.NET Core 3.0.0-preview8-27919-09
Slower	100.94	127.77	0.79	Windows 10.0.18362	64bit	Intel Core i7-5557U CPU 3.10GHz (Broadwell)	.NET Core 2.2.6	.NET Core 3.0.0-preview8-27919-09
Slower	77.25	97.51	0.79	Windows 10.0.18362	64bit	Intel Core i7-7700 CPU 3.60GHz (Kaby Lake)	.NET Core 2.2.6	.NET Core 3.0.0-preview8-27919-09
Slower	94.54	106.37	0.89	Windows 10.0.18362	64bit	AMD Ryzen 7 1800X	.NET Core 2.2.6	.NET Core 3.0.0-preview8-27919-09
Slower	91.95	107.41	0.86	Windows 10.0.18362	32bit	Intel Xeon CPU E5-1650 v4 3.60GHz	.NET Core 2.2.6	.NET Core 3.0.0-preview8-27919-09

/cc @danmosemsft @billwert @DrewScoggins

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 18 (18 by maintainers)

Most upvoted comments

hmm I think that GetCurrentProcess() should be modified to not allocate then Dispose() would not be needed to be called.

If you mean it would return a singleton, that could be problematic if it’s used concurrently by multiple threads, as various operations on Process are not thread-safe.

Dispose was fixed to be correct and that incurred a small penalty. In most situations, that overhead is not measurable. In the case of Process.GetCurrentProcess().Id, and other things like ProcessName, we now have properties on Environment (e.g. Environment.ProcessId) for returning that information that’s orders of magnitude faster and is the preferred path. We also have analyzers built in to the SDK that suggest folks use those instead.

I suggest we just close this issue.

stephentoub on Jun 18, 2021