Repository navigation
Bad Performance on first Power.From() call in .netCore #1126
Description
Description
The very first call on Power.From takes up to several seconds.
All the following calls are fine (regarding the performance).
Environment
- .net Core 3.1
- 32bit ARM Platform
- Embedded Linux
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.
Activity
angularsen commentedon Sep 8, 2022
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:
structtoclassto make use of inheritanceJens88 commentedon Sep 14, 2022
Hi
Thank you for the answer and the ideas how to deal with this.
I did not read all the release notes between V4.72.0 and V4.144.0.
But since you mentioned the large number of types and type members is the causing this issue;
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).
So this makes me think that there is yet another problem, unless you did add hundreds of types after V4.72.
angularsen commentedon Oct 31, 2022
@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.
#1069 (comment)
stale commentedon Jun 18, 2023
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.
Move unit abbreviation strings into culture-specific resource files (#…
angularsen commentedon Jul 11, 2023
@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.
Benchmark
Comparing 4.144.0 with latest v5.
Using TimeItSharp to run a net7.0 console app with this code:
Results
Before: 850 ms
After: 523 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)
angularsen commentedon Jul 11, 2023
@tmilnthorp Some benchmarks posted above, can't spot much different in v5 versions in this simple test setup, but significantly faster than v4.
🧪Add PerfTests for startup and JIT comparing v4 and v5 (#1283)
Jens88 commentedon Jul 11, 2023
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.
Jens88 commentedon Jul 11, 2023
So now the measurement of the very first call of Power.From() call:
V4.72 : 633ms
V4.144: 17256ms (this was the version i reported here)
V5.21 : 9121 ms
So to summarize:
angularsen commentedon Jul 11, 2023
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
JITStatsfor our 3 sample apps:PerfTests\PerfTest_Startup_v4_72_0PerfTests\PerfTest_Startup_v4_144_0PerfTests\PerfTest_StartupSummary of JIT durations
Quantitystatic.cctor()UnitAbbreviationsCache..cctor()UnitConverter.RegisterDefaultConversionsUnitConverter.SetConversionFunctionQuantityInfoUnitInfoQuantity.GetQuantityTypes(new)...HashSet`1[UnitsNet.Units...]System.LinqTake-aways
The main difference in 4.72 from 4.144 and latest:
QuantityInfo,SetConversionFunctionand various dictionaries/collection types.cctor(); onlyPower, QuantityInfo, QuantityFormatter, BaseUnits, UnitAbbreviationsCache. In v4.144 and latest it invokes ALL 120 quantity static constructors even if onlyPoweris used.If we can avoid invoking all static ctors for all 120 quantities, we should be able to improve this.
I'm not sure how much we can reduce the use of generics, it has some real benefits, but maybe there are some redundancies here.
PerfView data
Raw data here:
PerfViewData_UnitsNet_comparison_4.72_4.144_latest.xlsx
4.72
4.144
Latest
Anthonywolfe commentedon Apr 16, 2024
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