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

Avoid work inside of render() #50

Closed
wants to merge 1 commit into from
Closed

Conversation

lencioni
Copy link
Member

@lencioni lencioni commented Mar 4, 2017

Our HOC here is currently doing more work than is really necessary
inside of render. This can make updates slower than they need to be. To
optimize this some, I'm moving this work into the constructor and
componentWillReceiveProps to avoid unnecessarily repeating it.

@airbnb/webinfra

Our HOC here is currently doing more work than is really necessary
inside of render. This can make updates slower than they need to be. To
optimize this some, I'm moving this work into the constructor and
componentWillReceiveProps to avoid unnecessarily repeating it.
@@ -56,15 +75,7 @@ export function withStyles(
ThemedStyleSheet.flush();
}

const addedProps = {
[themePropName]: ThemedStyleSheet.get(themeName),
Copy link
Collaborator

Choose a reason for hiding this comment

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

Is ThemedStylesheet.get guaranteed to be idempotent based on the themeName?

If not, you may need to call it unconditionally in cWRP.

Choose a reason for hiding this comment

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

yes, it's guaranteed. get(x) === get(x). always. Similarly, styleDef(x) === styleDef(x) always, and only does a meaningful amount of work (ie, more than a hash lookup) on the first call. As a result, i'm not really sure that this PR will actually have a meaningful impact on performance, and could even be negative, due to the extra lifecycle events. Have we benchmarked any of this?

Copy link
Member Author

Choose a reason for hiding this comment

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

I haven't benchmarked yet. I plan to do that on Monday though!

Copy link
Collaborator

@ljharb ljharb left a comment

Choose a reason for hiding this comment

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

Code LGTM, pending benchmarks per @lelandrichardson's comment

@lencioni
Copy link
Member Author

lencioni commented Mar 6, 2017

Performance seems basically identical before and after this change, at least in Chrome, on a dev build of React.

@lencioni lencioni closed this Mar 6, 2017
@lencioni lencioni deleted the reduce-render-work branch March 6, 2017 20:59
@lelandrichardson
Copy link

Yeah, I wouldn't imagine this changing any of the performance characteristics. good to verify though!

If you're looking for ways to eek out performance for the style pipeline in react, we should chat. I have a couple of ideas that are react-primitives specific, but might end up applying here.

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.

None yet

3 participants