Avoid monomorphizing large functions multiple times #279
Labels
No labels
A-build
A-cli
A-core
A-design
A-edn
A-ffi
A-query
A-sdk
A-sdk-android
A-sdk-ios
A-sync
A-transact
A-views
A-vocab
P-Android
P-desktop
P-iOS
bug
correctness
dependencies
dev-ergonomics
discussion
documentation
duplicate
enhancement
enquiry
good first bug
good first issue
help wanted
hygiene
in progress
invalid
question
ready
size
speed
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: greg/mentat#279
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Related to #772.
Most of this is taken from https://gist.github.com/thomcc/09f48b222e4fdf69c43479ee65daf2ab (which is taken from a list of top functions of mentat_ffi when compiled as a cdylib)
If you look at that listing there are a number of duplicated functions, which are almost all going to be a result of the function being monomorphized multiple times. We should avoid these for anything large.
IntoIterator seems like a frequent offender here. In other code ,stuff like
Into
andAsRef
are often responsible.transact_entities
is duplicated at least twice and accounts for over 40kb according to cargo-bloat, , and probably could just take aVec<Entity<V>>
(this is still generic, but in practice TransactableValue is only ever ValueAndSpan AFAICT, so it will only be monomorphized a single time).transact_simple_terms
is likely the cause of the previous's bloat, and if it were only called with a single type it would likely not be getting inlined into transact_entities. Note also that we could fairly easily avoid the generic argument, since it's just used as something to pass toGeneration::from
.project_elements
should probably just take a Vec,There are probably more that just get inlined too and contribute to their caller getting bigger. There's a balance between this and performance though, so it's not 100% cut and dry, but for huge functions the overhead of e.g. collecting an iterator into a vector seems likely to be negligible.