AddAnyAttr working with erase_components #3518
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
cc #3156 #3458 #3460 #3461 #3476
TLDR: this PR enables
AddAnyAttr
onAnyView
when the--cfg erase_components
feature flag is enabled. Made possible by further type erasing tuples of attrs types toVec<AnyAttribute>
before they even became tuples preventing generation of an exponential number of types.--cfg erase_components
is now feature complete and provides up to 1.5-3x faster compilation speed. Yay!Unfortunately this means the issues surrounding
AddAnyAttr
andAnyView
without type erasure are most likely not an issue with rust or the compiler, but too many unique attribute tuple types, monorphisation and codegen, but importantly this missing feature is actually what is making stable leptos compile, by trimming the potential for futher attr types at eachAnyView
boundary and preventing further tuple types of that type being created, and why the feature cannot be enabled without reducing the number of unique types.Arguably the above is an issue with rust/the compiler, but on further analysis it looks like the solution isn't "fix a bug in rust/compiler" it's "how do we reduce the number of unique types without hurting binary size or runtime too much because the current number seems to be insane".
As I've mentioned, the compile bottleneck is only surrounding the static typing of attributes, not the entire view tree, which makes sense considering these are the "leaves" whereas html elements are the "branches". Maybe erasing attributes is a worthwhile cost, whilst leaving the tree itself static (i.e splitting
--cfg erase_components
into 2 parts, the attr part being erased.The main takeaway is that compiler issues, compile time, the
AnyAttr
feature not working onAnyView
, are all down to the tuple impls that create an exponential number of types.Using thaw's demo project, pointing leptos to this PR, you can see the effect of erasing the components with cargo-llvm-lines: llvm lines drop by 35% from 11million to 7million, still huge but it get's it down to something that seems manageable.
Without erasure:
With erasure: