- \n
- \u269b\ufe0f Components: like Inspect Element but with React tags<\/li>\n
- \u269b\ufe0f Profiler: the simple and excellent React Component Profiler<\/li>\n<\/ul>\n
Profiler Tab<\/h2>\n
Action Buttons<\/h3>\n
- \n
- <\/i> \/ <\/i> : Start \/ Stop profiling<\/li>\n
- <\/i> : Reload page and start profiling<\/li>\n
- <\/i> : Clear profiling data<\/li>\n
- <\/i> \/ <\/i> : Select previous \/ next commit<\/li>\n<\/ul>\n
Display<\/h3>\n
- \n
- <\/i> : Flamegraph chart<\/li>\n
- <\/i> : Ranked chart<\/li>\n<\/ul>\n
Interesting Settings<\/h3>\n
Filter the output once it becomes unwieldy in the <\/i> settings modal:<\/p>\n
- \n
Components > Hide components where...<\/code>: custom result filtering based on DOM type (ex: div), name, \u2026<\/li>\nProfiler > Hide commits below x ms<\/code>: ignore very fast renders (ex: re-renders for tooltips)<\/li>\n<\/ul>\nUsing the Profiler<\/h1>\n
Press the \u201c<\/i> Start profiling\u201d button, perform the action(s) that take too long and press the \u201c<\/i> Stop profiling\u201d button. Or use \u201c<\/i> : Reload page and start profiling\u201d when it\u2019s your initial page load that is taking too long.<\/p>\n
The default \u201c<\/i> : Flamegraph chart\u201d display is perfect as long as the next performance issues are easy to pick out.<\/p>\n
![\"\"](\"https:\/\/itenium-be.github.io\/blog-posts-new\/assets\/blog-images\/rcp-profiler-flamegraph.png\" "\\"\\"")
So what is this ‘InvoiceWorkedDays’ component?<\/figcaption><\/figure>\n Easy Pickings<\/h1>\n
\u23f1\ufe0f 6 seconds for 100 invoices\/rows.<\/p>\n
The first three profiling rounds revealed that the biggest issues were in non-component code:<\/p>\n
- \n
- Third Party Packages<\/strong>: Do not assume that free, open-source, packages will be performant.<\/li>\n
- Nested Loops<\/strong>: Several inner loops caused a significant CPU-bound delay.<\/li>\n
- Frequent I\/O<\/strong>:
sessionStorage<\/code> was being accessed for each component wrapped in a role check.<\/li>\n<\/ul>\n<\/p>\n
Culprit 1: Third Party Package<\/h2>\n
InvoiceWorkedDays<\/code>, the component in confac that was causing all this fuzz:<\/p>\n![\"\"](\"https:\/\/itenium-be.github.io\/blog-posts-new\/assets\/blog-images\/rcp-confac-invoice-list.png\" "\\"\\"")
An entire second spent on displaying an amount of days<\/figcaption><\/figure>\n The part that was eating up all this time was
date-holidays<\/code><\/a>, an npm package used to calculate the official Belgian holidays.<\/p>\nThe date-holidays can calculate holidays for Chinese, Korean and every other calendar out in existence. Because of the un-tree-shakable initialization
const hd = new Holidays('BE');<\/code> all the code for those calendars were also being parsed. Sub-dependencies includedastronomia<\/code><\/a>, leading to a footprint of about 10MB.<\/p>\nWe have since replaced the dependency with our own, dedicated (76 liner), npm package
@itenium\/date-holidays-be<\/code><\/a>.<\/p>\n<\/p>\n
Culprit 2: Nested Loops (CPU)<\/h2>\n
![\"\"](\"https:\/\/itenium-be.github.io\/blog-posts-new\/assets\/blog-images\/rcp-profiler-flamegraph-InvoiceDownloadIcon.png\" "\\"\\"")
Another unexpected performance optimalization target: the InvoiceDownloadIcon<\/figcaption><\/figure>\n \/\/ InvoiceDownloadIcon\nconst fullProjectMonth = useProjectMonthFromInvoice(invoice._id);\n<\/code><\/pre>\nThis custom Hook would first make a
FullProjectMonth<\/code> of all \u2018projectMonth\u2019 records in the Redux store and then pick the one withinvoice._id<\/code>.<\/p>\nProblem here was, that to resolve a \u201cprojectMonth\u201d, 5 other collections needed to be traversed as well. As the data grew, time spent here grew considerably.<\/p>\n
\/\/ fn mapToProjectMonth\nconst project = confacState.projects.find(p => p._id === projectMonth.projectId);\nconst consultant = confacState.consultants.find(c => c._id === project.consultantId);\nconst client = confacState.clients.find(c => c._id === project.client.clientId);\nconst partner = confacState.clients.find(c => project.partner && c._id === project.partner.clientId);\nconst invoice = confacState.invoices.find(i => i.projectMonth && i.projectMonth.projectMonthId === projectMonth._id);\n<\/code><\/pre>\nWe can greatly optimize this by first filtering on
invoice._id<\/code> so the 5 inner loops are executed just once!<\/p>\n<\/p>\n
Culprit 3: I\/O (sessionStorage)<\/h2>\n
\u23f1\ufe0f 2 seconds for 100 invoices\/rows.<\/p>\n
![\"\"](\"https:\/\/itenium-be.github.io\/blog-posts-new\/assets\/blog-images\/rcp-profiler-flamegraph-WithClaim.png\" "\\"\\"")
And now the WithClaim decorator??? What is happening there…<\/figcaption><\/figure>\n It\u2019s starting to become difficult to discern the next performance culprit. The second profiler display method \u201c<\/i> : Ranked chart\u201d to the rescue!<\/p>\n
![\"\"](\"https:\/\/itenium-be.github.io\/blog-posts-new\/assets\/blog-images\/rcp-profiler-WithClaim-ranked-graph.png\" "\\"\\"")
Profiler Ranked chart display<\/figcaption><\/figure>\n The Code<\/h4>\n
\/\/ The decorator\nexport const EnhanceWithClaim = <P extends object>(Component: React.ComponentType<P>) =>\n class WithClaim extends React.Component<P & EnhanceWithClaimProps> {\n render() {\n const {claim, ...props} = this.props;\n if (claim) {\n const claims: string[] = authService.getClaims();\n if (!claims.includes(claim)) {\n return null;\n }\n }\n return <Component {...props as P} \/>;\n }\n };\n\n\/\/ Wrap a component\nconst LinkWithClaim = EnhanceWithClaim(Link);\n\n\/\/ Usage\nconst CreateInvoiceLink = () => (\n <LinkWithClaim claim=\"invoice-create\" to=\"\/invoices\/create\">\n Create Invoice\n <\/LinkWithClaim>\n)\n<\/code><\/pre>\nThe culprit here turned out to be
authService.getClaims()<\/code>, which ended up doing the following for every of the hundreds of icons, buttons etc displayed.<\/p>\n\/\/ I\/O being executed many, many times == performance impact!\nconst token = sessionStorage.getItem('jwt');\n<\/code><\/pre>\n<\/p>\n
Alternatives<\/h2>\n
When you are rendering a grid with thousands of rows, you\u2019ll always going to end up with a performance problem (at some point).<\/p>\n
There are several mitigations:<\/p>\n
- \n
- Pagination<\/strong><\/i> Implemented!<\/li>\n
- Partial data load<\/strong>(only load last year worth of data in memory at startup)<\/small><\/i> Implemented!<\/li>\n
- Debouncing<\/strong>: Useful when filtering the grids, only start a re-render when the user is done entering the filter criteria<\/li>\n
- Virtualization & Infinite Scroll<\/strong>: A grid can display an \u201cinfinite\u201d amount of rows and still be performant!<\/li>\n
- Suspense & useDeferredValue<\/strong>: Not relevant here because all data is already in memory<\/li>\n<\/ul>\n
Conclusions<\/h2>\n
\u23f1\ufe0f 360 ms for 100 invoices\/rows.<\/p>\n
These were the \u201ceasy pickings\u201d, where the profiler\u2019s flamegraph gave it to us straight. This greatly improved performance (6s -> 360ms) which is good enough.<\/p>\n
- \n
- Not doing a calculation or render is the best optimalization<\/li>\n
- Keep an eye on 3rd party packages<\/li>\n
- I\/O operations are expensive<\/li>\n<\/ul>\n
<\/p>\n
The Meaty Part<\/h1>\n
There is another screen and performance there is\u2026 disastrous.<\/p>\n
- \n
- Everything is re-rendered whenever a projectMonth gets collapsed\/opened.\n
- \n
- Opening more and more projectMonths gets slower and slower.<\/li>\n
- \u23f1\ufe0f 2 open projectMonths: 350ms<\/li>\n
- \u23f1\ufe0f 4 open projectMonths: 1.2s<\/li>\n
- \u23f1\ufe0f 18 open projectMonths: 5s<\/li>\n<\/ul>\n<\/li>\n
- Filters are remembered between route changes.\n
- \n
- Navigating back can be painfully slow when many projectMonths were open.<\/li>\n
- \u23f1\ufe0f With 18 open projectMonths: 4.4s<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
![\"\"](\"https:\/\/itenium-be.github.io\/blog-posts-new\/assets\/blog-images\/rcp-confac-projectMonths.png\" "\\"\\"")
The projectMonths screen — open up more months and you can go get a coffee in between renders \ud83d\ude22<\/figcaption><\/figure>\n <\/p>\n
Belgian Holidays Cache<\/h2>\n
For this workshop,
date-holidays<\/code> was not replaced with a more dedicated and efficient alternative. Instead we\u2019re using it as a placeholder for something that would actually take a long time and cannot be so easily improved.<\/p>\nTo get to the following flamegraph, we added a simple cache for the
date-holidays<\/code> dependency.<\/p>\nconst workDaysInMonthCache: {[month: string]: number} = {};\n<\/code><\/pre>\n![\"\"](\"https:\/\/itenium-be.github.io\/blog-posts-new\/assets\/blog-images\/rcp-profiler-flamegraph-projectMonths.png\" "\\"\\"")
A more even distribution now… So no easy performance targets<\/figcaption><\/figure>\n Avoiding IFeature Construction<\/h2>\n
The
IFeature<\/code> configures a grid and CRUD pages for a backend entity.<\/p>\nIt contains the data and currently active filters. The problem here is that the
openMonths: string[]<\/code> filter is also part of the data of theIFeature<\/code>.<\/p>\nBecause of how Redux works, the
openMonths: string[]<\/code> filter becomes a new array reference each time a projectMonth is opened\/collapsed. This causes all months to be re-rendered instead of just the one being toggled because the filters object has changed.<\/p>\nFurthermore, the expensive
IFeature<\/code> construction is not necessary when the projectMonth is collapsed. Instead we can map directly toCollapsedProjectMonthBadgeTotals<\/code>, which doesn\u2019t include any inner loops.<\/p>\nexport const ProjectMonthsList = ({feature, month}: ProjectMonthsListProps) => {\n \/\/ If this isn't a Demeter violation, I don't know what is \ud83d\ude13\n if (feature.list.filter.state.openMonths.includes(month)) {\n return (\n <>\n <Toolbar feature={feature} \/>\n <List feature={feature} \/>\n <\/>\n );\n }\n\n \/\/ When the ProjectMonth is collapsed, we don't\n \/\/ really need to construct the IFeature...\n return <ProjectMonthListCollapsed feature={feature} \/>;\n};\n<\/code><\/pre>\n<\/p>\n
Introducing: Reselect<\/h2>\n
A library for creating memoized \u201cselector\u201d functions<\/a>. Commonly used with Redux and comes with the @reduxjs\/toolkit<\/a>.<\/p>\n
Caching the expensive mapping to
FullProjectMonthModels<\/code> &CollapsedProjectMonthBadgeTotals<\/code> withcreateSelector<\/code>:<\/p>\n\/\/ Create the selector\nimport { createSelector } from 'reselect';\n\nexport const createFullProjectMonthsSelector = () => createSelector(\n \/\/ Select required store data\n \/\/ Re-renders happen when these references change\n (state: ConfacState) => state.projectsMonth,\n (state: ConfacState) => state.projects,\n (state: ConfacState) => state.consultants,\n\n \/\/ Introduce a \"month\" parameter for the selector\n (_, month: string) => month,\n\n \/\/ The actual mapping\n (projectsMonth, projects, consultants, month) => {\n const context = { projectsMonth, projects, consultants }\n return projectsMonth\n .filter(x => isSameMonth(x.month, month))\n .map(x => mapToProjectMonth(context, x));\n },\n\n \/\/ Optional configuration\n {\n memoizeOptions: {\n equalityCheck: (a, b) => a === b, \/\/ ex: use deep-equal instead\n maxSize: 10, \/\/ selector cache\n \/\/ import { shallowEqual } from 'react-redux';\n resultEqualityCheck: shallowEqual\n }\n }\n);\n<\/code><\/pre>\n<\/p>\n
Introducing: useMemo<\/h2>\n
Skip expensive recalculations with
useMemo<\/code><\/a><\/p>\nuseMemo(calculateValue, dependencies)\n<\/code><\/pre>\nWe now need to cache the
createFullProjectMonthsSelector<\/code> mapped data for each month. Because we want to keep a memoized version of each month, we pass an empty array as the dependencies argument to useMemo.<\/p>\nIf you need to cache only until the month changes, as in when you are navigating from one detail page to another, the dependencies would become
[month]<\/code>.<\/p>\n\/\/ Selector usage\nimport { useMemo } from 'react';\n\nexport const OpenedProjectMonthsList = ({ month }: OpenedProjectMonthsListProps) => {\n \/\/ Use the createSelector as defined above\n \/\/ With empty array as dependencies argument\n const selectProjectMonths = useMemo(createFullProjectMonthsSelector, []);\n\n \/\/ Use the memoized selector\n const projectMonths = useSelector(state => selectProjectMonths(state, month));\n\n \/\/ And construct the IFeature\n return <List feature={projectMonthFeature(projectMonths)} \/>;\n};\n<\/code><\/pre>\n<\/p>\n
Introducing: memo<\/h2>\n
When a
ProjectMonthListCollapsed<\/code> is rendered, its details don\u2019t change, so we can do some aggressive caching there, keeping the entire rendered component in the cache withReact.memo(component, propsAreEqual?)<\/code><\/a>.<\/p>\nimport { memo } from 'react';\n\n\/\/ Memoize the component for each value of month\nconst ProjectMonthListCollapsedMemo = memo(({ month }) => {\n return <ProjectMonthListCollapsed month={month} \/>;\n});\n\n\nexport const OpenOrClosedProjectMonthsList = ({ month }) => {\n const isOpen = useSelector(state => state.filters.projectMonths.openMonths[month]);\n if (isOpen) {\n return <OpenedProjectMonthsList month={month} \/>;\n }\n return <ProjectMonthListCollapsedMemo month={month} \/>;\n};\n<\/code><\/pre>\n<\/p>\n
The Aftermath<\/h2>\n
![\"\"](\"https:\/\/itenium-be.github.io\/blog-posts-new\/assets\/blog-images\/rcp-profiler-projectMonths-final.png\" "\\"\\"")
Flamegraph after opening a second projectMonth<\/figcaption><\/figure>\n - \n
- No re-render of the previously opened projectMonth (reselect & useMemo)<\/li>\n
- The render of the newly opened projectMonth<\/li>\n
- The completely cached collapsed\/closed projectMonths (memo)<\/li>\n<\/ol>\n
Conclusions<\/h2>\n
- \n
- \u23f1\ufe0f 2 projectMonths: 350ms -> 170ms<\/li>\n
- \u23f1\ufe0f 4 projectMonths: 1.2s -> 311ms<\/li>\n
- \u23f1\ufe0f 18 open projectMonths: 5s -> 140ms<\/li>\n<\/ul>\n
The biggest win was avoiding the re-renders of all projectMonths when opening\/closing just one and caching expensive Redux selects.<\/p>\n
Take-Aways<\/h3>\n
- \n
- Depend on as little as possible\n
- \n
- Components should rely on their minimum requirements of state and props only<\/li>\n
- Prefer props only for low level components<\/li>\n<\/ul>\n<\/li>\n
- Cache expensive calculations<\/li>\n
- createSelector, useMemo and memo are your friends<\/li>\n<\/ul>\n
The IFeature<\/h4>\n
\n
\u201cWeeks of coding can save you hours of planning.\u201d<\/em> \u2014 Fred Brooks<\/p>\n<\/blockquote>\n
Unexpected Side-Effect<\/h3>\n
The overall structure and code quality has improved due the refactorings needed to realize the performance targets.<\/p>\n
- \n
- More components with finer grained purpose resulted in a clearer component hierarchy<\/li>\n
- Complexity has increased but it is hidden away in hooks and selectors<\/li>\n<\/ul>\n
Profiler Alternatives<\/h1>\n
If the Chrome Profiler Extension isn\u2019t cutting it for you anymore, you can still fallback to these alternatives for locating performance optimalization targets.<\/p>\n
console.time<\/h2>\n
Good old console<\/a> \ud83d\ude09<\/p>\n
console.time('timer1')\n\nconst result = expensiveOp1()\nconsole.timeLog('timer1', 'result is', result)\nexpensiveOp2()\n\nconsole.timeEnd('timer1')\n<\/code><\/pre>\nProfiler Component<\/h2>\n
<Profiler \/><\/code><\/a> doesn\u2019t actually render anything and can be nested by providing different ids.<\/p>\nimport { Profiler } from 'react';\n\nfunction callback(\n id, \/\/ the \"id\" prop of the Profiler tree that has just committed\n phase, \/\/ either \"mount\" (if the tree just mounted) or \"update\" (if it re-rendered)\n actualDuration, \/\/ time spent rendering the committed update\n baseDuration, \/\/ estimated time to render the entire subtree without memoization\n startTime, \/\/ when React began rendering this update\n commitTime, \/\/ when React committed this update\n interactions \/\/ the Set of interactions belonging to this update\n) {\n console.log(`${id}: ${phase} in ${actualDuration}`);\n}\n\nconst LongRendering = () => (\n <Profiler id=\"uniqueId\" onRender={callback}>\n <LongRenderingItem \/>\n <\/Profiler>\n)\n<\/code><\/pre>\nFor a simple case like this with only one
<Profiler<\/code>, you are better off just using the Chrome extension.<\/p>\nIt can come in handy for micro optimizations, using multiple
<Profiler \/><\/code>s and hundreds\/thousands of components. At that point you will need to write your own aggregator in the callback to make some sense of the data.<\/p>\nA simple aggregator on
ID<\/code>:<\/p>\ntype ITiming = {\n renders: number;\n totalTime: number;\n averageTime?: number;\n}\n\nconst timings: {[key: string]: ITiming} = {}\n\nfunction callback(id, phase, actualDuration) {\n if (!timings[id]) {\n timings[id] = {renders: 1, totalTime: actualDuration};\n } else {\n const oldTimings = timings[id];\n timings[id] = {\n renders: oldTimings.renders + 1,\n totalTime: oldTimings.totalTime + actualDuration\n };\n }\n\n timings[id].averageTime = timings[id].totalTime \/ timings[id].renders;\n}\n<\/code><\/pre>\nFurther Optimalizations<\/h1>\n
- \n
- Avoid inline styles<\/li>\n
- useCallback<\/strong><\/a>: cache event handlers\n
- \n
- Tricky: useCallback also takes time; in my case it actually degraded performance<\/li>\n
- As always with perf optimizations \u2013> MEASURE<\/strong> (the profiler is your friend)<\/li>\n<\/ul>\n<\/li>\n
- memo<\/strong>: Components without props can be cached entirely<\/li>\n
- useWhyDidYouUpdate<\/strong><\/a>: part of many hooks-libraries (I didn\u2019t find it very useful)<\/li>\n
- useDebugValue<\/strong><\/a>: to be used in custom hooks (more for library developers IMO)<\/li>\n<\/ul>\n
Extras<\/h1>\n
Stuff that came into being during the making of this post<\/b><\/p>\n
- memo<\/strong>: Components without props can be cached entirely<\/li>\n
- Depend on as little as possible\n
- Everything is re-rendered whenever a projectMonth gets collapsed\/opened.\n
- Partial data load<\/strong>(only load last year worth of data in memory at startup)<\/small><\/i> Implemented!<\/li>\n
- Nested Loops<\/strong>: Several inner loops caused a significant CPU-bound delay.<\/li>\n
- <\/i> : Ranked chart<\/li>\n<\/ul>\n
- <\/i> : Reload page and start profiling<\/li>\n
- <\/i> \/ <\/i> : Start \/ Stop profiling<\/li>\n
![](\"https:\/\/img.shields.io\/github\/stars\/amsterdamharu\/selectors.svg?style=social&label=Star\")
<\/a>![](\"https:\/\/img.shields.io\/github\/stars\/facebook\/react.svg?style=social&label=Star\")
<\/a>