React-native-web: ScrollView: investigate expensive layout measurements

[brunolemos]

What is the current behavior?

When scrolling, there is a huge lag.
Chrome shows some warnings on console that could help find the issue.

Most violations point to UIManager measureLayout), the last one to a debounce function:

[Violation] 'requestAnimationFrame' handler took 93ms
[Violation] Forced reflow while executing JavaScript took 184ms
[Violation] 'requestIdleCallback' handler took 242ms
[Violation] 'setTimeout' handler took 74ms

Steps to reproduce

_Tried to create a minimal test case on codepen but could not. Maybe it's because my component tree is relatively deep and heavy styled (ps: using styled-components). Added you to the repository so you can run it. PS: On mobile, works fine. Bad performance only on web._

1. Accept my invitation to the repo
2. yarn
3. cd web/
4. yarn
5. npm start (on web folder)
6. Open notifications tab
7. Scroll vertically

Environment (include versions)

OS: macOS 10.12.4
Device: Macbook Pro 2016
Browser: Chrome 58.0
React (version): 16.0.0-alpha.6
React DOM (version): 15.5.4 _(react-native-web does not support >= 16)_
React Native (version): 0.43.2
React Native for Web (version): 0.0.94

[brunolemos]

I'm running some profiling to try to narrow it down...
Everything seems to come back to UIManager measureLayout/getRect functions

UIManager/index.js

[brunolemos]

Maybe some tips so my component measure layouts faster?

[RangerMauve]

Maybe there's a way to improve performance by using Element.getBoundingClientRect()

[necolas]

Are you using the onContentSizeChange callback?

If you're using styled-components with RN/RNW that is also likely to be very slow and wasteful.

[brunolemos]

@necolas thanks for the answer.

I'm not using onContentSizeChange or something similar on my code, but there is indead a onLayout=bound_handleContentOnLayout on my react tree that internally calls onContentSizeChange and apparently it's coming from the react-native-web ListView Component

[RangerMauve]

@brunolemos Is your ListView deeply nested within your app?

[brunolemos]

@RangerMauve yes, it's trello-like

[RangerMauve]

The getRect function you pointed up above will be slower depending on how deeply nested it is within the DOM. I'm not 100% certain, but I think that Element.getBoundingClientRect() might be faster alternative.

Regardless, this means that ListViews are a huge performance issue if they're not near the root of your DOM, and more generally onLayout is a huge performance issue if it's not called near the root.

[brunolemos]

Found out something (kinda obvious but might help).

The ListView is initially rendering 10 item.
When I scroll, it adds more items.

If I set initialListSize={100}, app is slower to start but the scroll gets much better.
I guess this multiple row addition + measureLayout on a deep listview is making things slow.

[necolas]

Yeah the ListView is not really worked on, not performant, and will be removed once React Native deprecates it. getBoundingClientRect doesn't return the correct values (for RN) when scale transforms are applied to the element, but I'll look at alternative ways to correct the value without iterating up the tree.

[tazsingh]

I've done a benchmark of getBoundingClientRect yesterday to see if it would be any faster for #474, but the performance of it was generally 20% slower than the current method.

[necolas]

o_O

[tazsingh]

Haha I was also shocked as I was expecting it to be faster for sure. Thought it would be quick win but nope... And I'm kind of confused why as everything that I know suggests that it should be faster... But hey if it doesn't work then it doesn't work. Thought I'd loop back here to say that it's also not more performant.

[tazsingh]

Can you let me know if #490 solves some of this for you?

[necolas]

Might still be worth using getBoundingClientRect if there are performance issues with the current approach in deeply nested trees of nodes

[brunolemos]

I just noticed my component tree go down to ~100 items deep. That's insane. Also lot's of Connect(XXX), withXXX and other wrappers.

So although there are improvements to be made on react-native-web layout measuring code, I really need to do some work on my part too.

[RangerMauve]

@brunolemos Yeah, I had a similar problem. I also hacked React.createElement so that it would execute any stateless functions as functions if they didn't need to be components for stuff like context

[aFarkas]

@brunolemos
Can I have access to your repo. I'm interested to look into this. (Although, I'm only interested in perf issues that are caused by forced sync reflows.)

[brunolemos]

@aFarkas you can see it running here: http://brunolemos.github.io/devhub/

edit: this link is for the old slow version

I didn't make the code public yet neither shared the project with anyone.

[brunolemos]

I rewrote my app from scratch and I don't have this issue anymore. Performance is great.

As I didn't isolate the issue, I don't know the real cause of it, but one of the changes was that I removed styled-components and took extra care to avoid unnecessary re-renders.

[necolas]

Thanks for following up!