The wrapRender method could become de-optimized after a playing for a while.
Also the method was called for many invisible views (ineffective calls to the method).
The idea was to try to stop the de-optimization from happening and improving the subview system to make sure that invisible views wouldn't create overhead in the rendering pipeline.
A few other implementation details surrounding the wrapRender method could be fixed.
How
By adding a list of visible views to BaseBacking it was possible to remove the overhead of invisible classes. These visible views are still ordered in the same way, i.e with respect to z-index first and then added order.
The _renderSubviews method has been removed.
Some attributes that were added to instances of BaseBacking after instantiation time were removed, such as the _sortKey.
The _addedAt method is now initialized in the constructor to make sure that all the hidden classes that go through the wrapRender method contain it (<= goal is to limit the number of different hidden classes going through the wrapRender method).
The opts of the wrapRender method has been removed. It was apparently used only by the ScrollView in order to communicate viewport information. This viewport information now only exists locally in the ScrollView.
The sort method now take a comparison method as opposed to sorting views based on their stringified sorted keys.
Result
Chrome (macbook) profiling
Before
After
The wrapRender method in itself went from number 1 to number 2. The _renderSubviews method has now completely disappeared. They accounted for 16.5% of the resources before the refactoring down to 9% after.
Safari (iPhone 7) profiling
Before
After
The wrapTick + _renderSubviews method went from ~11% to 6%.
Chrome (macbook) measure
The measurements of the Engine's tick also are showing good improvements
Before
After
The FPS in gameplay phase on Xperia Z3 seems to be higher, now in the 50~60fps range in light gameplay.
The gameplay benchmark shows an non-idle time of 11.64%, down from 13.5%! (still on my machine)
Overall it looks like another ~10% CPU gain.
Sorting
The new sorting seems to give better performance. To test it I enforced the sort to happen every frame for every view:
Before
After
Total time taken by the sorting is down from 10% to 4%. Conclusion: using a comparison method for sorting appears more efficient than sorting elements as strings. Of course the in-game benefit is smaller but considering the sorting now happens more often I thought it might be best to optimize the sorting.
bchevalier
commented
7 years ago
Why
The
wrapRendermethod could become de-optimized after a playing for a while. Also the method was called for many invisible views (ineffective calls to the method). The idea was to try to stop the de-optimization from happening and improving the subview system to make sure that invisible views wouldn't create overhead in the rendering pipeline. A few other implementation details surrounding thewrapRendermethod could be fixed.How
BaseBackingit was possible to remove the overhead of invisible classes. These visible views are still ordered in the same way, i.e with respect to z-index first and then added order._renderSubviewsmethod has been removed.BaseBackingafter instantiation time were removed, such as the_sortKey._addedAtmethod is now initialized in the constructor to make sure that all the hidden classes that go through thewrapRendermethod contain it (<= goal is to limit the number of different hidden classes going through thewrapRendermethod).optsof thewrapRendermethod has been removed. It was apparently used only by theScrollViewin order to communicate viewport information. This viewport information now only exists locally in theScrollView.Result
Chrome (macbook) profiling
Before
After
The
wrapRendermethod in itself went from number 1 to number 2. The_renderSubviewsmethod has now completely disappeared. They accounted for 16.5% of the resources before the refactoring down to 9% after.Safari (iPhone 7) profiling
Before
After
The
wrapTick+_renderSubviewsmethod went from ~11% to 6%.Chrome (macbook) measure
The measurements of the Engine's
tickalso are showing good improvements BeforeAfter
The FPS in gameplay phase on Xperia Z3 seems to be higher, now in the 50~60fps range in light gameplay.
The gameplay benchmark shows an non-idle time of 11.64%, down from 13.5%! (still on my machine) Overall it looks like another ~10% CPU gain.
Sorting
The new sorting seems to give better performance. To test it I enforced the sort to happen every frame for every view: Before
After
Total time taken by the sorting is down from 10% to 4%. Conclusion: using a comparison method for sorting appears more efficient than sorting elements as strings. Of course the in-game benefit is smaller but considering the sorting now happens more often I thought it might be best to optimize the sorting.
Note: Refactoring of dom ViewBacking not tested!