-
Notifications
You must be signed in to change notification settings - Fork 47.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible v8 de-opt for profiling react-dom bundles #14365
Comments
cc @bmeurer and @mathiasbynens |
Yes, sorry @mathiasbynens. I jumped the gun by creating this issue and tagging you before I remembered that I needed to check with @uriklar for permission before sharing his part of the repro case with you. Hopefully I'll get confirmation soon and will leave a comment here when I do. |
I mean, the more minimal the repro, the better. |
Understood. What I meant was that he provided the repro case and I tracked it down and added the annotations to |
I dug more into this tonight and found that the issue seemed to be around the fact the the properties being set were This definitely seems like a bug in V8, as using any other browser does not exhibit the same performance issues. Could having |
Hi @bvaughn , It's ok to invite any individuals you need to the repo. But if you want to make it public I would need to change the data in it.. EDIT: I see the repo contains some git history of files I removed from the original project to create the minimal repo. Before granting anyone access I would need you (or I can do it too) to create a fresh repo with the files but no git history. Sorry about making a git soup... :-/ |
It’s okay, we can wait for a reduced test case. |
Ok i just removed the git history from Brian's repo so he can give you access now |
Thanks @uriklar! @bmeurer and @mathiasbynens, you should have access now. Please let me know if anything doesn't make sense. |
Alright, we’ll take a look after the weekend :) |
Looking into this with @mathiasbynens today, we found that the root cause is somehow related to double field related instance migrations combined with The work-around for that on your side is to make sure to either have the time values represented as diff --git a/vendor/react-dom.development.js b/vendor/react-dom.development.js
index 94b4662..78137cd 100644
--- a/vendor/react-dom.development.js
+++ b/vendor/react-dom.development.js
@@ -9765,10 +9765,10 @@ function FiberNode(tag, pendingProps, key, mode) {
this.alternate = null;
if (enableProfilerTimer) {
- this.actualDuration = 0;
- this.actualStartTime = -1;
- this.selfBaseDuration = 0;
- this.treeBaseDuration = 0;
+ this.actualDuration = Number.MIN_VALUE;
+ this.actualStartTime = -1.1;
+ this.selfBaseDuration = Number.MIN_VALUE;
+ this.treeBaseDuration = Number.MIN_VALUE;
}
{ to make sure the fields are all initialized to doubles from the beginning (as a cleaner fix I'd suggest to use |
@bmeurer @mathiasbynens A huge thanks to both of you for looking into this issue! :) |
We have a simple repro for this problem and filed v8:8538 to track this. |
@bmeurer Thanks for tracking this internally so quickly. Out of curiosity, do you know if the same issue exists when using |
|
Thanks so much for the info @bmeurer! |
Initializing the values to My testing seems to suggest that it's sufficient to initialize the fields to double values as you've described, and then immediately replace those values with |
Do you have an estimated time for this to be released? |
Not currently. I'll bring it up with the team today and see if we can't prioritize one soon though. |
@bvaughn They can hold integers, no problem. It's just that they should start with doubles, otherwise the instances need to transition from Smi fields to Double fields eventually, which triggers the bug. As long as they start out as Doubles, no migration is needed. |
Thanks for confirming! 😄 |
Hey @bvaughn do you know now if this will be released soon? I don't want to be annoying, but we are stuck on 16.4 because of this. 😆 |
Don't know, no. It's been released in the last several |
@bvaughn I've tried again to update from 16.4.1 to 16.7.0 and I still have some leaks / high memory issues. 😱 Here's a capture of my task manager: We have several apps in my company and only one faces this issue... How could I try a development version of the devtools to investigate better? |
This issue was about fibers being slow for property lookup– so apps were slower, but I don't think it necessarily had any impact on memory usage. (So I think what you're reporting is probably unrelated?) If you can share your source code, you might want to file a new issue with some info:
|
I managed to isolate the component that is responsible for the issue. It uses I'll try to setup a reproduction example 🙂 |
Issue created: #14574 |
At some point this trick was added to initialize the value first to NaN and then replace them with zeros and negative ones. This is to address the issue noted in #14365 where these hidden classes can be initialized to SMIs at first and then deopt when we realize they're actually doubles. However, this fix has been long broken and has deopted the profiling build for years because closure compiler optimizes out the first write. I'm not sure because I haven't A/B-tested this in the JIT yet but I think we can use negative zero and -1.1 as the initial values instead since they're not simple integers. Negative zero `===` zero (but not Object.is) so is the same as far as our code is concerned. The negative value is just `< 0` comparisons.
At some point this trick was added to initialize the value first to NaN and then replace them with zeros and negative ones. This is to address the issue noted in #14365 where these hidden classes can be initialized to SMIs at first and then deopt when we realize they're actually doubles. However, this fix has been long broken and has deopted the profiling build for years because closure compiler optimizes out the first write. I'm not sure because I haven't A/B-tested this in the JIT yet but I think we can use negative zero and -1.1 as the initial values instead since they're not simple integers. Negative zero `===` zero (but not Object.is) so is the same as far as our code is concerned. The negative value is just `< 0` comparisons. DiffTrain build for commit 94e4aca.
At some point this trick was added to initialize the value first to NaN and then replace them with zeros and negative ones. This is to address the issue noted in #14365 where these hidden classes can be initialized to SMIs at first and then deopt when we realize they're actually doubles. However, this fix has been long broken and has deopted the profiling build for years because closure compiler optimizes out the first write. I'm not sure because I haven't A/B-tested this in the JIT yet but I think we can use negative zero and -1.1 as the initial values instead since they're not simple integers. Negative zero `===` zero (but not Object.is) so is the same as far as our code is concerned. The negative value is just `< 0` comparisons. DiffTrain build for [94e4aca](94e4aca)
I've observed that when React's profiling mode is enabled, updating the profiling fields here and here during the render phase seems to cause a significant deopt in
getHostSibling
during the commit phase for Chrome only. (Neither Safari nor Firefox seem to be affected by this.)I have created a repro case with inline annotations here:
https://github.com/bvaughn/react-profiling-v8-deopt-repro#about-this-repro-case
(Note that the above repo is private. Please tag me here if you need access.)
The text was updated successfully, but these errors were encountered: