You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
js-framework-benchmark shows a serious problem in the "create many rows" benchmark. My initial analysis points to the following method appear way too often on the stacktrace (recursively):
I believe the check in NodeRef::link causes a very long chain of linked node refs to be traversed. I'm not certain yet why such a long chain exists in the first place. It might be connected to a specific order in which the lifetime methods of components are called. Before a component is rendered, a node ref is still created and linked to its successor. This could cause such a huge chain, and most likely O(n^2) behaviour in large lists.
Why does it not show up in our benchmarks? The regression might have been introduced before these were established.
Anyway, I'll see if I can come up with a fix. This might be the time to rework NodeRefs overall. The current design seems especially vulnerable to this accidental n^2 behaviour.
The text was updated successfully, but these errors were encountered:
That can't be all of it. The speedup from the linked PR is approximately x2 on my machine, far outside the margin of error of different runs. I'm currently reading the workflow files to look for anything out of the ordinary.
js-framework-benchmark shows a serious problem in the "create many rows" benchmark. My initial analysis points to the following method appear way too often on the stacktrace (recursively):
yew/packages/yew/src/html/mod.rs
Lines 93 to 97 in 9e980a3
I believe the check in
NodeRef::link
causes a very long chain of linked node refs to be traversed. I'm not certain yet why such a long chain exists in the first place. It might be connected to a specific order in which the lifetime methods of components are called. Before a component is rendered, a node ref is still created and linked to its successor. This could cause such a huge chain, and most likely O(n^2) behaviour in large lists.Why does it not show up in our benchmarks? The regression might have been introduced before these were established.
Anyway, I'll see if I can come up with a fix. This might be the time to rework
NodeRef
s overall. The current design seems especially vulnerable to this accidental n^2 behaviour.The text was updated successfully, but these errors were encountered: