-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
.NET 8.0.10 vs 9.0.0 RC2 GC Server Performance Regression in Sep (CSV Parser) Benchmark (due to DATAS default) #109047
Comments
Try with DATAS disabled e.g. |
Command I run from branch
No change with
|
Yes, it's DATAS. Tried settings it with environment variable e.g. for BDN with NO DATAS
DATAS
|
yeah a throughput regression for certain microbenchmark scenarios is expected with DATAS. Assume the benchmark shows improved working set utilization? |
It is expected in .NET 9. In general, DATAS should benefit real-world applications a lot as it can largely reduce the working set and also improve GC latency, though it comes with a minor throughput penalty. In another similar issue (#101006) I did a binary-tree allocation benchmark and got the following benchmark result on .NET 9 rc2: Considering the large improvements to latency and working set, I would take the minor throughput perf regression. |
In https://github.com/nietras/Sep (a fast highly optimized CSV parser) I have been comparing performance
comparison-bench.ps1
between .NET 8 and .NET 9 RC2 and have observed what appears to be consistent and significant performance regression when usingServerGarbageCollection
(true
). The benchmark in question is also discussed in https://www.joelverhagen.com/blog/2020/12/fastest-net-csv-parsersBenchmarks can be run by cloning the Sep repo, checking out branch
net9.0
and running the command in thecomparison-bench.ps1
perhaps adding--filter *GcServer*Sep*
or similar. Details for benchmark, machine are given below via BenchmarkDotNet.As can be seen this shows regression in a scenario of many medium size object allocations ranging from 500ms/429ms = 1.17x (single thread) to 174ms/102ms = 1.69x (multi-threaded) regression.
I know there have been changes to the GC my question is whether this regression is expected? And just wanted to flag it if it has any interest.
The text was updated successfully, but these errors were encountered: