Bad Performance on first Power.From() call in .netCore #1126
Labels
Comments
|
Hi, this is a known issue: #965 Due to a large number of types and type members for all our 100+ quantities and 1000+ units, the JIT spends a long time on the initial usages. We don't currently have a solution to this, but a few ideas have been floated:
|
|
Hi Did you add a lot of new types after V4.72.0? I know i run on a "low power" cpu and thus i cannot compare my time measurement with all the benchmark tests done listed in issue #965. But the difference between the two versions i mentioned is a factor of 100 times slower (or even more). |
|
@Jens88 I'm not sure, we added a bunch of units for sure, but 100x sounds a lot. Are you able to profile the difference between the two? Maybe find what exact hotspot in the code differs between them. Maybe we have introduced some regression. There was one known performance regression, but it should have been fixed in 4.142.0. |
1 task
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
angularsen
added a commit
that referenced
this issue
Jun 18, 2023
…1210) Fixes #1126 Refs #1238 A quick draft to move the unit abbreviations into resource files. I also want to move methods for getting culture-specific abbreviations to the individual quantities. This should: - Reduce initialization time by removing the MapGeneratedLocalizations methods (TODO) - Reduce in-memory footprint by only loading a requested culture - Allow formatting to use methods on the quantities themselves - Which should allow for better extensibility as well - Remove the unit abbreviations cache (deprecate) ### TODOs - [ ] Test fallback to invariant culture `export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT='1'` #1238 --------- Co-authored-by: Andreas Gullberg Larsen <andreas.larsen84@gmail.com>
|
@JeCodeFu Long overdue, but I think this improved a lot in v5, plus some recent improvements in #1210. Could you give it another go? I can't replicate the extreme slowness you reported though, since you were testing on ARM32 and I'm testing on a fast computer:
Maybe the application complexity and size also affects how much work JIT needs to do for UnitsNet. BenchmarkComparing 4.144.0 with latest v5. Using TimeItSharp to run a net7.0 console app with this code: Console.WriteLine(Power.From(5, PowerUnit.Watt));ResultsBefore: 850 ms This includes the overhead of starting and running the console app. The idea was to capture any slowness in the JIT. Before (v4.144.0)For some reason this crashed the timeit tool, so I had to run fewer iterations on this nuget.
After (v5)
|
|
@tmilnthorp Some benchmarks posted above, can't spot much different in v5 versions in this simple test setup, but significantly faster than v4. |
angularsen
added a commit
that referenced
this issue
Jul 11, 2023
Dump some tests used to benchmark #1126
|
Hi Andreas Thanks for the update on this issue. Since we went back in version we had no actual suffer anymore. I quickly tested the newest version. Unfortunately all the "Undefined" entities vanished, so my code needs some adaption to get back running again. I will come back to this thread when I converted the code and have a test setup again. |
|
So now the measurement of the very first call of Power.From() call: V4.72 : 633ms So to summarize:
|
|
cc @tmilnthorp Thanks for reporting back and testing again. Clearly we did something between 4.72 and 4.144 to make the JIT choke hard on this platform, that is still not fixed in v5. I don't have much time to profile and look into this anytime soon, but I did run PerfView to get the
Summary of JIT durations
Take-awaysThe main difference in 4.72 from 4.144 and latest:
If we can avoid invoking all static ctors for all 120 quantities, we should be able to improve this. PerfView dataRaw data here: 4.72
4.144
Latest
|
|
Hi, I want to throw in some performance metrics I've measured on my Arm64 device. Environment:
Due to some shenanigans I end up loading 4 instances of UnitsNet using a AssemblyLoadContext, Though that's outside of the scope of this issue and I'm just bringing it up to explain why RegisterDefaultConversions shows up 4 times in the below image. Here are some measurements I got from DotTrace I'm still a bit new to this tool so if there is any more in-depth info you'd like me to grab I can.
Stacktrace |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description
The very first call on Power.From takes up to several seconds.
All the following calls are fine (regarding the performance).
Environment
Repro/Code
var result = Power.From(5, PowerUnit.Watt);Expected behavior
The call should return within milliseconds, but it takes up to more than 10 seconds.
Additional context
I Experienced this issue after updating from Version 4.72.0 to Version 4.144.0.
It did not happen in the older version.
The text was updated successfully, but these errors were encountered: