Skip to content
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

Prevent performance regression in DEV due to warning arguments #7461

Merged
merged 2 commits into from
Aug 10, 2016
Merged

Prevent performance regression in DEV due to warning arguments #7461

merged 2 commits into from
Aug 10, 2016

Conversation

gaearon
Copy link
Collaborator

@gaearon gaearon commented Aug 10, 2016

Expensive arguments shouldn’t be calculated if the warning doesn't fire.
This fixes a few cases where that calculation might be more expensive than usually.

In my testing, this brings down average row click time in Power Editor from ~300ms to ~220ms in __DEV__ (vs ~40ms in prod).

This only affects Facebook website, not open source version of React.

On the Facebook website, we don't have a transform for warnings and invariants.
Therefore, expensive arguments will be calculated even if the warning doesn't fire.
This fixes a few cases where that calculation might be more expensive than usually.

In my testing, this brings down average row click time in Power Editor from ~300ms to ~220ms in __DEV__ (vs ~40ms in prod).
@@ -69,7 +69,7 @@ if (__DEV__) {

if (standardName != null) {
warning(
standardName == null,
false,
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are just consistency changes. The original code is kinda odd with two checks.

@gaearon gaearon changed the title Prevent internal performance regression Prevent performance regression in DEV due to warning arguments Aug 10, 2016
@ghost ghost added the CLA Signed label Aug 10, 2016
@gaearon
Copy link
Collaborator Author

gaearon commented Aug 10, 2016

It is probably better to fix this right in fbjs: https://github.com/facebook/fbjs/blob/21f1f725e00de4c70f60b45f9db641b2a98e149c/packages/babel-preset-fbjs/plugins/dev-expression.js#L115

But this wouldn’t help us internally.

@jimfb
Copy link
Contributor

jimfb commented Aug 10, 2016

👍

@gaearon gaearon added this to the 15-next milestone Aug 10, 2016
@gaearon gaearon merged commit 178cb7d into facebook:master Aug 10, 2016
@gaearon gaearon deleted the faster-www branch August 10, 2016 18:52
@zpao zpao modified the milestones: 15.3.1, 15-next Aug 12, 2016
zpao pushed a commit that referenced this pull request Aug 12, 2016
* Prevent internal performance regression

This only affects Facebook website, not open source version of React.

On the Facebook website, we don't have a transform for warnings and invariants.
Therefore, expensive arguments will be calculated even if the warning doesn't fire.
This fixes a few cases where that calculation might be more expensive than usually.

In my testing, this brings down average row click time in Power Editor from ~300ms to ~220ms in __DEV__ (vs ~40ms in prod).

* Put warning() that shows up in profile behind condition

(cherry picked from commit 178cb7d)
@sahrens
Copy link
Contributor

sahrens commented Aug 16, 2016

I think we have an invariant transform that does this automatically - could we apply the same thing to warning instead of doing it manually like this?

@sahrens
Copy link
Contributor

sahrens commented Aug 16, 2016

Or is that what you were referring to in your comment about dev-expression.js?

@zpao
Copy link
Member

zpao commented Aug 16, 2016

Yea, dev-expression does it for invariant already & we could do it for warning too, but we don't do that transform internally so we'd still paying the cost on www (not in RN though as that uses the version of React we compile here).

@sassanh
Copy link
Contributor

sassanh commented Aug 28, 2016

@gaearon I just updated to 15.3.1 and saw a great performance improvement (my incremental build time reduced from ~10 sec to ~4 sec.) I traced it and read the change log and saw that you did a lots of commits to improve performance. I just wanna thank you for your efforts and really appreciate that (and I'm sure as you know I'm just one out of many who appreciates it.) It really made life easier for me as waiting ~4 sec for each change is much much better than ~10 sec :-)

Sorry if it's not the appropriate place for saying thanks but couldn't find better place for saying so.

@gaearon
Copy link
Collaborator Author

gaearon commented Aug 28, 2016

@sassanh

Interesting, this is actually not related and was probably caused by something else.
We were fixing the runtime performance of development build, not build speeds.

@sassanh
Copy link
Contributor

sassanh commented Aug 29, 2016

I see, that's still valuable and I'm still thankful, though I wish I could find the one who reduced my wasted time waiting for compilation by 60% and thank him but I guess it takes so much time (Going through repositories of libraries I use and check them commit by commit and find out which commit did the magic!). Maybe we should improve git-bisect and develop an application called "Find the one you want to thank" for this purpose 😃

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants