3 ms·
Any idea on how one could optimize the rendering function to reduce this lag (which BTW I can barely see on my 2015 MBP)?
by GiovanniFrigo 11y ago
Any idea on how one could optimize the rendering function to reduce this lag (which BTW I can barely see on my 2015 MBP)?
- iandanforth 11y agoCacheing? You're doing a lot of work in render that could be computed once. Try saving a few years +/- into state on componentDidMount. And for day clicks, pull rows that arn't touched from the cache.
- GiovanniFrigo 11y agoWill surely do, thanks! Also, how did you test the onClick delay? by spamming timestamps in the code? :D
- exizt88 11y agoUse the Chrome's "Profiles" tab in DevTools.
- sirrocco 11y agoNo, you open up the Chrome Dev Tools, click the Timeline tab and then start recording. Click a few days in the calendar, stop the recording and then you'll see that after each click it takes 100ms until paint events are shown.
- jkkramer 11y agoThings would also be significantly sped up if you compiled in production mode. From looking at your source, all the dev mode checks are still being performed. See: https://facebook.github.io/react/downloads.html https://facebook.github.io/react/downloads.html (the note under npm section) https://github.com/facebook/react/issues/1772 https://github.com/facebook/react/issues/1772 http://stackoverflow.com/questions/22118915/how-to-turn-on-off-reactjs-development-mode http://stackoverflow.com/questions/22118915/how-to-turn-on-o...
- GiovanniFrigo 11y agoThanks! Useful links, I didn't know anything about this. Will surely start using the `NODE_ENV=production` environment variable from now on!
- GiovanniFrigo 11y agoThat reduced the click delay from approx 90ms to 67ms, that's a pretty solid -25% there! Thanks for the suggestion, @jkkramer!
- guscost 11y agoOne common optimization is to strategically use shouldComponentUpdate to limit the number of components that render each time the state changes. In this case you could create a Month component which renders a single <tr> element. This component would then implement shouldComponentUpdate to check if the state used to render that month has changed. If not, shouldComponentUpdate returns false and the month does not re-render. This means that clicking on a Day should re-render two Months at most. The same shouldComponentUpdate optimization could be added to both Calendar and Day, but in this case clicking a Day would always require the Calendar to re-render, and running through 365 shouldComponentUpdate functions (returning false from at least 363 of them) without first limiting by Month would not be ideal. If the state is managed with ImmutableJS or a similar library, shouldComponentUpdate would only have to do a single reference equality check. Either way you should see a big improvement from any implementation that allows the individual Month components to skip rendering: http://facebook.github.io/react/docs/advanced-performance.html http://facebook.github.io/react/docs/advanced-performance.ht...
- GiovanniFrigo 11y agoGreat! thanks for the explanation and the docs!
- Buetol 11y agoDelay is 50ms on my MBP. Here is a profile: http://i.imgur.com/ty11Utl.png http://i.imgur.com/ty11Utl.png With the main bottleneck being here: https://github.com/BelkaLab/react-yearly-calendar/blob/master/src/Calendar.js#L56-L82 https://github.com/BelkaLab/react-yearly-calendar/blob/maste... Implementing a good shouldComponentUpdate() should fix it.