[Android] Extreme lag after upgrade to 0.39.2 and 0.40.0 #11809
Comments
|
Were you able to confirm that the slowdown is because of more onLayout callbacks happening without actual changes to layout? |
|
@sahrens Yes, I built RN from source from the commit before and all was good ... |
|
I can confirm this problem in my application, i have updated from 0.36 to 0.40 and UI becomes unusable after render 100 items in a simple listview where the rows are only text and image. |
|
I have tested today 0.41.0-rc.1 - still the same. |
|
I'm facing the same issue, any progress or workaround? |
|
Have no idea what to do. It actually forced me to stop working on my project(( I have no time to dig into debugging and so on.
…Вторник, 31 января 2017, 17:05 +03:00 от Neo ***@***.***>:
I'm facing the same issue, any progress or workaround?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub , or mute the thread .
|
|
two screenshots of android profiler when I scroll listview:
|
|
I want to add my voice to this chorus. I upgraded from 0.34.1 to 0.40. I was pleasantly surprised by some of the improvements (Dailymotion working well within the Webview, some keyboard problems fixed, screen rotation with better behavior) but then I realised the performance drop. I was close to releasing my app but the problem is so bad I have to wait. Still waiting. Coded as a stop-gap a simple page trick with only 50 elements per page to ensure smooth scrolling and touch responses. And this is is on a Samsung S6. Performance is significantly worse on lower-end/older devices. |
|
We're seeing the exact same issue here as well, iOS works fine, Android has become very laggy post update. |
|
Same here |
|
Same here. We had to downgrade to 0.38. |
|
And same here. Hopefully this can be addressed soon. |
|
This wouldn't be related to that commit -- it's more likely related to #11222 (is anyone able to try reverting that locally and see if the problems go away?) I'll post internally and try to get someone on it. |
|
The commit of #11222 was cherry-picked into 0.38 and 0.39. People are reporting the bug doesn't happen on 0.38. So maybe this PR is not the root cause? |
|
0.38.0 is different from 0.38.1 |
|
Reverting that commit makes quite a large difference to us - I'm not 100% certain that performance is back to what it was before 0.39 - we'll continue testing. |
|
which commit should I revert to temporarily fix the problem? |
|
It depends of your RN version as it was cherry-picked in the previous releases: For 0.38, a simple way to revert it is to switch from 0.38.1 to 0.38 and see if the problem goes away. I don't have a way to reproduce the bug so I can't test it. But I guess the final solution to this is not to simply revert this commit because it fixes a bug for me and for other people. Basically, we have to get rid of the performance problem without breaking what it solved. |
|
I have a fix in review internally that I'll hopefully get in today. I'll make sure it gets cherry-picked into the next release. |
|
@astreet |
|
I'm not sure on the feasibility of that, @mkonicek? |
Summary: Developers are complaining about horrible lag (#11809) caused by PR #11222. The issue was that hasNewLayout in yoga is actually a dirty bit and indicates that either you OR one of your children has a new layout. We still need to manually check whether the component's layout actually is different from before. Reviewed By: sahrens Differential Revision: D4597545 fbshipit-source-id: 27d4605afd00badfdcdacae740ee2e477adee929
|
Fix is in: 15429e3 Let's make sure it doesn't break anything internally and then we can see about getting it cherry-picked. |
|
Just tested the fix on my test repo with the bug and it didn't break! |
|
I tested in 0.44.0-rc.0 and its fixed, thanks! :) |
|
Hey @grabbou |
|
@grabbou I noticed 0.43.1 didn't include the yoga fixes, is it possible to cherry pick them or do they depend other commits? The matching commits in React native are: |
|
Yeah, I've already talked to Emil about that. Will release one more version
later today
…On Wed, Apr 5, 2017, 11:05 Andrew Jack ***@***.***> wrote:
@grabbou <https://github.com/grabbou> I noticed 0.43.1
<https://github.com/facebook/react-native/commits/0.43-stable> didn't
include the yoga fixes, is it possible to cherry pick them or do they
depend other commits?
The matching commits in React native are:
***@***.***
<facebook/yoga@5884ab7>
= 759b8cc
<759b8cc>
***@***.***
<facebook/yoga@5112564>
= f1371ec
<f1371ec>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#11809 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACWcxk5zfKD_hRk8hWwtOx3lf5gC-1dMks5rs1lqgaJpZM4Lfm7J>
.
|
|
0.43.2 is now on Circle and should be on |
|
Having said so, can this issue be closed now? |
|
I have tested this and can confirm it is fixed. A big thanks to everyone involved!!! You can close this. |
|
Are you sure this is fixed? I have just finished converting a screen from using I'm on react-native v0.43.3. It initializes slowly, taking at least 5 seconds for the initial render, then in the perf monitor the JS thread says During this time the app is completely locked up, except for scrolling the list, which seems to work. The One interesting thing is that if I enable Any clues? |
|
@andreialecu this issue affected ListView and SectionList similarly I believe, so if you weren't seeing any issues on ListView then my guess is you accidentally introduced some weird perf regression with your transition to If you can't sort out the problem, can you provide a repro case/sample code? |
|
It seems like switching JS Dev mode to off helped the problem somewhat, as did removing a few Now it renders almost instantly (or at least without any perceived lag), but the JS thread still stalls bouncing between -2.1 fps, 2.1 fps for close to 10 seconds until it recovers. All my section headers and list items are However, if I trim down the The original list item component itself is not super complicated, but has several nested This didn't seem to be as much of a problem with And if I run it with |
|
Alright, I kept the code for the However, now that I got rid of the It still seems like |
|
I'm still having the weird issue that @andreialecu discussed earlier using 0.43.3. On a physical device our app seems to run incredibly slow becoming unresponsive unless I have remote debugging turned on. Without remote debugging I will drop to -2.0 fps for 10-20 seconds and then will come back up. During this time the app is not responsive. When I turn on remote debugging I average 50-60 fps. I do not have any console.logs or redux logger turned on. I have also created a new react-native project and moved my files over with the same issues. At first I thought it could be a redux / data store issue problem. The only problem i see with that is iOS would be affected also. Any help / ideas would be appreciated. |
|
@joshualcoffee Can you take and post a systrace (see #11809 (comment))? |
|
@astreet Sure thing. I have created a few videos of a scaled down app vs a larger app. https://www.dropbox.com/s/bh2dkjd8svh00uf/2017_04_20_07_08_23.mp4?dl=0 https://www.dropbox.com/s/9qu0o93naqfsjmk/2017_04_20_07_14_57.mp4?dl=0 Systrace: |
|
@joshualcoffee are you using the new In general, the entire app seems slightly faster with There is also a related |
|
It's not surprising at all that that things would be faster with remote debugging compared to running on a slow Android device. The marshaling overhead is actually quite small compared to the computation. |
|
Ahhh well that's good to know. I think the issue is comparing it to developing on iOS. Typically you will get slower performance when you have remote debugging on during iOS simulation. If this is typical than disregard my comments. FlatList still seems to be a huge issue for android. Following up what @andreialecu, I had to switch back to |
|
Hey guys I'm noticing the exact thing @joshualcoffee is after upgrading to 0.43.4. Unusable slow performance but only on an iOS physical device in debug mode, yet turning on remote debugging actually solves the issue. Only using Did the fix mentioned above land in 0.43.4 or 0.44.0 or not at all yet? Thanks for the help! react-native 0.43.4 |
Summary: Developers are complaining about horrible lag (facebook#11809) caused by PR facebook#11222. The issue was that hasNewLayout in yoga is actually a dirty bit and indicates that either you OR one of your children has a new layout. We still need to manually check whether the component's layout actually is different from before. Reviewed By: sahrens Differential Revision: D4597545 fbshipit-source-id: 27d4605afd00badfdcdacae740ee2e477adee929
|
Hello. I`ve same issue. |
|
Same after upgrading from 0.42 to 0.48.3 |
and others
Description
Updating from 0.36.0 to 0.39.2 and 0.40.0 renders the app unusable after minimal interaction. The javascript thread slowly grinds to a halt until it becomes unresponsive. Native UI, such as scrolling or native animations is unaffected. Problem persists with 0.41.0-rc.0
It works perfectly well with 0.38.0
Reproduction
I managed to reproduce this in a freshly installed app with an infinite scroll list containing rows with images. With 0.40.0, the JS driven animation begins to lag after only ~150 items. WIth 0.38.0, animation stays smooth as long as there is no rendering.
See attached videos below:
0.38.0
0.40.0
Test app can be found here
A relative StackOverflow question.
Solution
I suspect the new C-based CSS implementation, as that is the only major change from 0.38 to 0.39. Another reason could be a problem with removeClippedSubviews.
Additional Information
The text was updated successfully, but these errors were encountered: