Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We memo all the things (2020)

attardi.org

Post reply on HN
Print view View original

31–40 of 84 posts

Re: We memo all the things (2020)

#31

Post by wpietri »

Zababa wrote: post #15
jasonkillian wrote: post #3

This is a great article and I agree with it fully. The argument that a lot of popular React voices have made, "React is fast and it's prematurely optimizing to worry about memoizing things until a profile shows you need it", has never rung true with me. First and foremost, there's a huge time cost to figuring out what those exact spots that need optimization are, and there's also an educational cost with teaching les…

I've always thought of "premature optimisation" as optimising something that's not your "hot path". If there's no clear hot path, everything is the hot path, and small optimisation gains everywhere are the only thing you're going to get. So at this point, it's not premature. You could also rewrite your code so that there is a clear hot path, but in that case it seems to be React rendering, that's optimised by using m…

How could you not have a hot path? You're saying that you've measured actual usage and discovered that each thing happens to be called exactly the same number of times? That strikes me as extraordinarily improbable.

Re: We memo all the things (2020)

#32

Post by jbaudanza »

vlunkr wrote: post #30

> If you’ve ever profiled a React app – even in production mode – you know there is a non-negligible performance impact to every component that renders. Maybe it's just me, but I've used React for ~5 years and I've never needed to profile an app, since the performance out of the box has always been good enough.

The situation is much more severe with react-native, which doesn’t have a JIT compiler available.

Re: We memo all the things (2020)

#33

Post by eatonphil »

fouric wrote: post #29
eatonphil wrote: post #4

I like React a lot and have used it professionally for more than 5 years. First off I mostly haven't needed to memoize any time I can remember in any enterprise (non-SaaS) production or personal apps. But surely CoinBase is at a bigger scale than my apps were/are. But if it's the case that memoizing is such a good thing to do despite the effort (and I'm not debating that in this question), why is React designed in a…

What does "needed" mean in "I mostly haven't needed to memoize any time I can remember"? Does it mean that that your manager/team lead has never asked you to? Or that your production builds always hit some performance benchmark? Or that your development builds hit that benchmark? Or that you never noticed a qualitative slowdown in your development environment? Or something else? "Needed" is a word you gotta define wh…

There was never a slowness in the apps I've worked on that came down to requiring memoization in React versus other basic things like doing pagination or other ways of rendering only things that would be displayed at the time for the user.

Re: We memo all the things (2020)

#34

Post by steve_adams_86 »

I don’t disagree that this likely improves performance in most cases, and I don’t blame the author here for any of my concerns.

We’ve implemented this in our code base and it’s awful. Yes it improves performance. It also makes debugging terrible. Combined with contexts, the react dev tools are virtually useless anywhere below a context with a memoized value.

Profiling is harder because of frameworky misdirections as well. You can do coarse benchmarks but actually following code in a profile gets noticeably worse once you memo everything.

I hope this is fixed. I really enjoy react, but this odd thing about it - that we arguably should memoize everything manually, and that it does make the dev tools a mess, is a huge hit to developer experience.

So tired of “Component did not render” in the Component tab.

Re: We memo all the things (2020)

#35

Post by wpietri »

jasonkillian wrote: post #3

This is a great article and I agree with it fully. The argument that a lot of popular React voices have made, "React is fast and it's prematurely optimizing to worry about memoizing things until a profile shows you need it", has never rung true with me. First and foremost, there's a huge time cost to figuring out what those exact spots that need optimization are, and there's also an educational cost with teaching les…

It seems to me you're being pretty breezy about readability. At most places, developer time is by far the most expensive commodity, and the limiting factor in creating more user value.

In particular, bad readability is one of the sources of a vicious circle where normalization of deviance [1] leads to a gradual worsening of the code and a gradual increase in developer willingness to write around problems rather than clean the up. Over time, this death by a thousand cuts leads to the need for a complete rewrite, because that's easier than unsnarling things.

For throwaway code, I of course don't care about readability at all. But for systems that we are trying to sustain over time, I'm suspicious of anything that nudges us toward that vortex.

[1] https://en.wikipedia.org/wiki/Normalization_of_deviance

Re: We memo all the things (2020)

#37

Post by psadri »

ramesh31 wrote: post #28
jon-wood wrote: post #6

This feels to me like another example of how the drive to use nothing but functional components in React is harming readability. Class based components were allowed to define a `shouldComponentUpdate` method which would be called ahead of rendering to decide whether a re-render is needed. Having the parent component memoise the component instead feels like a step backwards as we're now asking the parent to carry an u…

Have you ever dug through a complex heavily nested application trying to debug a performance issue, only to find a custom shouldComponentUpdate method within every individual component? It makes debugging an absolute nightmare.

What is your proposed alternative?

Re: We memo all the things (2020)

#38

Post by jdjb »

nfRfqX5n wrote: post #19
eatonphil wrote: post #4

I like React a lot and have used it professionally for more than 5 years. First off I mostly haven't needed to memoize any time I can remember in any enterprise (non-SaaS) production or personal apps. But surely CoinBase is at a bigger scale than my apps were/are. But if it's the case that memoizing is such a good thing to do despite the effort (and I'm not debating that in this question), why is React designed in a…

the only time I find it to be required is when passing in callbacks to custom hooks with props that may change and you'll notice immediately because the callback will continuously run

If you're using React.useCallback to avoid triggering further hooks down the line, then you're using it wrong. Since React.useCallback is ostensibly just React.useMemo wrapped around a function, this note in the documentation is just as applicable:

  You may rely on useMemo as a performance optimization, not as a semantic guarantee. In the future, React may choose to “forget” some previously memoized values and recalculate them on next render, e.g. to free memory for offscreen components. Write your code so that it still works without useMemo — and then add it to optimize performance.

Re: We memo all the things (2020)

#39

Post by notpachet »

psadri wrote: post #37
ramesh31 wrote: post #28

Earlier quoted context omitted.

Have you ever dug through a complex heavily nested application trying to debug a performance issue, only to find a custom shouldComponentUpdate method within every individual component? It makes debugging an absolute nightmare.

What is your proposed alternative?

Not the OP, but in a word: Redux.

Re: We memo all the things (2020)

#40

Post by napsterbr »

jasonkillian wrote: post #3

This is a great article and I agree with it fully. The argument that a lot of popular React voices have made, "React is fast and it's prematurely optimizing to worry about memoizing things until a profile shows you need it", has never rung true with me. First and foremost, there's a huge time cost to figuring out what those exact spots that need optimization are, and there's also an educational cost with teaching les…

> has never rung true with me.

Yeah, me neither. I'm seeing first-hand a "large" (but probably not Coinbase-large) webapp dying by 10 thousand cuts.

The "you shouldn't care if it rerenders" components are, together, affecting performance. Going back and memoizing everything would be a nightmare and not a viable business solution. Rewrite everything from scratch is also not viable. So we have to live with a sluggish app.

At the same time, memoizing everything does make your code unreadable.

Honestly, it's a mess. I only accept working with this kind of stuff because I'm very well paid for it.

On my personal projects I stay far away from the Javascript ecosystem, and it's a bless. Working with Elm or Clojurescript is a world of difference.

Clojurescript's reframe, by the way, uses React (via Reagent) and something somewhat similar to Redux, without having any of the pitfalls of modern JS/React.

I can write a large application and ensure that there are no unnecessary rerenders, without sacrificing readability and mental bandwidth by having to memorize everything.

The conclusion I have, which is personal (YMMV) and based on my own experience, is that modern JS development is fundamentally flawed.

Apologies for the rant.

Post reply on HN