Disable costly eventManager support when unused. #14756
Conversation
For every event that we observe (which is basically all bubbling events in the DOM) we would iterate the entire `parentView` structure of the target elements view looking for an `eventManager` (and then we would dispatch the event to the `eventManager` instead of the view itself). This support has existed for a *very* long time, and is generally unused in most applications. Unfortunately, the iteration upwards through the view heirarchy is much more costly than we would like. This is currently being done for events like `mouseenter` and `mousemove` and that very very very few applications (if any) actually take advantage of this support. This changes the `EventDispatcher` to (by default) disable support for `eventManager`'s (and avoids the costly `parentView` iteration) until we actually instantiate a component that has an `eventManager` property. In the future, we should deprecate specifying an `eventManager`, but this makes the feature much more "pay as you go".
|
@GavinJoyce - Would you like to work on the deprecation RFC (we can use the same conditional to add the deprecation)? |
|
Nice one!
Sure, I'll work on the RFC and deprecation |
|
@rwjblue I'd have thought this would be a huge performance win, do you have any idea how big? |
|
@jonnii - I agree it should have a nice perf win, but haven't really done any testing. Most of the benchmarks I've been running locally are specifically testing initial render or rerender performance, and those types of tests generally wouldn't benefit from this (AFAICT). I think the types of things that would benefit would be rerenders where many events are firing. I'd definitely be interested in some numbers if you happened to have a perf testing harness setup in this way... |
For every event that we observe (which is basically all bubbling events in the DOM) we would iterate the entire
parentViewstructure of the target elements view looking for aneventManager(and then we would dispatch the event to theeventManagerinstead of the view itself).This support has existed for a very long time, and is generally unused in most applications. Unfortunately, the iteration upwards through the view heirarchy is much more costly than we would like. This is currently being done for events like
mouseenterandmousemoveand that very very very few applications (if any) actually take advantage of this support.This changes the
EventDispatcherto (by default) disable support foreventManager's (and avoids the costlyparentViewiteration) until we actually instantiate a component that has aneventManagerproperty.In the future, we should deprecate specifying an
eventManager, but this makes the feature much more "pay as you go".Related to #14754