-
Notifications
You must be signed in to change notification settings - Fork 289
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
Optimize wasmi::Linker
host function setup
#989
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #989 +/- ##
==========================================
+ Coverage 81.81% 81.89% +0.08%
==========================================
Files 262 262
Lines 24110 24186 +76
==========================================
+ Hits 19726 19808 +82
+ Misses 4384 4378 -6 ☔ View full report in Codecov by Sentry. |
According to our benchmarks those string type wrappers and their custom Ord implementation improve Linker performance by roughly 50%. This is probably because the Rust compiler is able to inline the `memcmp` routines whereas with `Arc<str>` and `str` it uses `memcmp` calls which are inefficient for small strings.
The new implementation optimizes the Ord impl of ImportKey since ImportKeys are compared more often than their fields are queried during Linker setup.
This allows us to create new HostFuncTrampolineEntities without an Engine and thus allow for a HostApi abstraction later to further optimize Linker setup. Also conveniently this allow us to get rid of tons of custom Debug implementations to resolve the no longer existing DedupFuncTypes.
The new experimental |
Closes #979.
cc @athei
Most inefficiencies are in
StringInterner::get_or_insert
and inmemcmp
calls to compare definition names.Findings
""
name for themodule
name for all host functions we can improve performance by ~15%.memcmp
.struct LenOrder(Arc<str>)
andstruct LenOrderStr(str)
wrapper types with newOrd
implementation to avoidmemcmp
are very effective, improving performance by roughly 50%. Unfortunately this requires a single line ofunsafe
Rust code since Rust'sBTreeMap
does not support custom comparators.