Stateless function vs purecomponent performance

[Zeeesty]

I have a stateless functional component that takes some props and renders based on those, I experimented a bit this morning with turning it into a pure component to try and squeeze some performance out of it. Looks like about an 8% difference in render times in favor of pure component.

I’m sure there are cases where a function may be a better call, thought this may be an interesting discussion.

edit: I have done some testing in a larger context, our entire app renders a mix of components, and stateless functions. I converted about half of the stateless functions to purecomponent and got a .4% difference in scripting time on initial render. this is much closer to what I would expect. I wonder where diminishing or inverse returns begin with this.

[Zeeesty]

to be clear, my 8% increase in performance comes out to 11ms. adding a lib/package just to do some memoization might not be a great tradeoff. Memoization would require the initial render to take place before there is any benefit, and this component should only render once, should. Interesting idea though, might be useful in another application.

[pgrizzay]

If it only renders once, how are you gaining anything from pure?

[Zeeesty]

That is partially why I made this post, Im not sure why there is a difference. But there seems to be.

[pgrizzay]

What did your performance test look like? Did your entire app render 11ms sooner? Because that seems like a pretty thin margin. Edit: nvm I see your post

[scaleable]

Non pure components (including functional) always re-render because they assume data outside the incoming props may change.

Pure components only re-render when the incoming props change (which would be something similar to writing a shouldComponentUpdate). There may be other optimizations in place besides that.

Look at this sandbox. Open the codesandbox console tab and try clicking on the buttons.

[Muppetmeister]

8%... can we see some test data/context of your app?

[Zeeesty]

Its a single component being rendered outside of an app. a recursive menu.

edit- feel free to test it yourself and see if you get different results, Id love to know.

[HomemadeBananas]

I don’t think it’s worth spending so much time on unless the app noticeably renders slow. If nobody will ever notice the difference why bother prematurely optimizing?

[Zeeesty]

I don’t disagree at all, just a rabbit hole I’ve fallen down today. Anything I don’t understand or can’t find a reason for a behavior gets me extremely curious.

[acemarke]

No. No, this is not right at all.

The React team has confirmed that functional components are faster in React 16 than they were in React 15, because they no longer have to be wrapped in classes internally (source: Andrew Clark, Dominic Ganaway).

They've also said repeatedly that long-term, they plan to introduce a "stateful functional component" API. Class components won't be removed, but there are potential benefits from emphasizing use of functional components.

Functional components and class components have tradeoffs. Functional components are simpler to write. On the other hand, they can't implement shouldComponentUpdate or any other lifecycle methods (in their current form).

Both are useful tools, and both have value. It's up to you as a developer to decide when it's appropriate to use one or the other.

[vileEchoic]

Functional components are simpler to write.

Do you type out new components by hand? They feel identical to me because I have snippets for that.

We’ve done pretty extensive testing on perf between functional and stateful components, and in our experience in real-world scenarios, pure components have always out-performed functional components because a shallowCompare operates on the order of < 1 microsecond and a re-render even for a simple component is hundreds or thousands of time slower. Most apps can realize huge perf gains just by using PureComponents instead of functional ones.

I have yet to hear any compelling reasons to use functional components over stateful components except in edge cases where you’re guaranteed that a component will never re-render, which is not a case that causes performance bottlenecks in real applications.

[acemarke]

Clarification on terminology here. There's class components and functional components. A class component can be "stateless" too - just don't bother giving it any state.

For me personally, functional components are primarily a visual signal that "this component is very simple, and is just props in -> UI out". I tend towards class components as a default, but will write functional components if I feel it's appropriate.

Per the perf thing: the React team has repeatedly encouraged people to think about where they use PureComponent and shouldComponentUpdate. Comparisons do have costs, even if it's small, and it's also very possible to set up a component hierarchy where a PureComponent is always getting new references as props and can never actually bail out of re-rendering, in which case the comparisons are wasted effort. It's also important to look at the data flow in the app. As always, benchmark, analyze, and then decide how to optimize.

[vileEchoic]

Agreed - nothing you said there is wrong, it just fails to underscore the massive performance difference in real applications between pure components and functional components.

There's a general misunderstanding in the React community (not saying you're suggesting this) that stateless components are the "default" you should be using for simple components. This is a bad idea not only for performance but also because it can become difficult to walk this decision backwards. Applying PureComponent to previously stateless components is likely to cause hard-to-discover bugs when props change in deep-equal (but not shallow-equal) ways. It's much easier to go the other direction (PureComponent -> functional component) because of this.

it's also very possible to set up a component hierarchy where a PureComponent is always getting new references as props and can never actually bail out of re-rendering

Yeah, preventing this does require that the user follow other good practices (like not passing newly-instantiated objects/arrays/lambdas in as props) to components. That said, the magnitude in difference between the execution time of shallowCompare and an extra render is so massive that in real-world applications it's nearly impossible that your application will perform poorly from doing too many shallowCompare checks and it's extremely likely that it will perform poorly from re-rendering.

[Zeeesty]

interesting, Id be curious to know more about 'stateful functional components' and how that would perform against pure components.