perf: element event batch triggering #2005
Draft
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.
🤔 This is a ...
🔗 Related issue link
💡 Background and solution
Problem Description:
In the current implementation, it is necessary to traverse the list of elements in the scene graph multiple times, which has an impact on performance, and the superposition effect of different events exacerbates the performance problem.
This pattern of traversing elements and triggering events is a bit like the early web standard
MutationEvent
, which has been deprecated and replaced byMutationObserve
. It can be seen that this is an anti-pattern.see https://developer.chrome.com/blog/mutation-events-deprecation
In addition, the performance problem of this implementation is obvious, so G uses the reuse mechanism of event objects to improve performance, but this approach has been proven to be insignificant. At the same time, we also conducted a simple test:
see facebook/react#18216
Solution:
The processing of internal element events is changed to batch triggering.
Impact:
ElementEvent.BOUNDS_CHANGED
(internal)📝 Changelog
☑️ Self Check before Merge