avm1: Store childNodes on the node itself #13319
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.
I didn't do benchmarks yet. I can also add a test later.
This should help #13130 .
In general, this should make repeated
.childNodes
a free op, at the cost of making mutations (.appendChild
etc) more expensive (O(n_children)
* but only if.childNodes
was read at least once before).This is not just an optimization, but also a correctness fix, as the array mutations can be observed in AS.
(*which implies that appending N elements is
O(n^2)
. I confirmed that FP has the same quadratic time complexity, though without benchmarks I can't tell whether we'll turn out faster or slower)Unfortunately it's ugly due to current design. Ideally we'd want to refresh the array each time a mutation of a
XmlNode
(xml/tree.rs
) happens, but this refresh is an AVM1 operation that technically can throw an AVM1 error, which makes actually calling this fromtree.rs
much harder.Any advice? 😅