[Bug] Evaluate use of string comparisons inside Maui.Core #3085
Labels
legacy-area-perf
Startup / Runtime performance
platform/android 🤖
s/verified
Verified / Reproducible Issue ready for Engineering Triage
t/bug
Something isn't working
t/perf
The issue affects performance (runtime speed, memory usage, startup time, etc.) (sub: perf)
Milestone
Description
From @grendello
with Profiled AOT and dotnet/android#6311 this PR we can get it down to less than 900ms
with a sample that has a handful of controls (11 I think)
I see that MAUI Core uses a lot of dictionaries with culture-aware string comparer
it's a major source of slowdown usually
it might be a good idea to use StringComparer.Ordinal if possible
or StringComparer.OrdinalIgnoreCase if needed
one result in the above PR is interesting, namely the Displayed time for default settings (i.g. no AOT)
it shows that MAUI spends a LOT of time JIT-ing between OnCreate is called and the activity is fully rendered
this goes away with Profiled AOT, which is faster by ~400ms than the default settings
one of the speed ups in the above PR is that we no longer use string comparison when searching for assemblies as Mono requests them of us
what is done instead, is we generate on build time the name hashes and store the lookup tables sorted by hash (separately for 32 and 64-bit apps)
and then when Mono asks us to load the assembly, we generate the hash from provided name and use that to binary search the table of known assemblies
perhaps MAUI could do that with some of string processing you do?
we're using xxHash which is very, very fast
https://cyan4973.github.io/xxHash/
The text was updated successfully, but these errors were encountered: