You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We finally enabled React compiler on our library; Results were mounts went from 40ms -> 80ms which is a 2x regression. We started to investigate why and what the emission looks like and what our thoughts are this which I wanted to get some advice on:
When the original code goes in, more conditionals are added in all cases; More conditionals mean more CPU cycles, mean less performance.
A lot of memory is stored via "$" which looks like a more optimised version of the memoization React provides internally. This will actually move more memory from the stack to the heap as variables who's values were not memoized AND not referenced in any event callbacks, would naturally be stored in stack memory by V8 or any other engine.
Byte-size; If I take a simple component look at the before/after it goes from like 245 bytes to 429 bytes.
SSR - If the emitted code can only ever make mounts slower AND lots of memory is moved to the heap; Doesn't this simultaneously mean SSR throughput will regress and has no potential to improve? GC Cycles will be longer, More conditionals = mounts will be longer. Does this mean we're expected to build our apps twice now for SSR? Once without React compiler enabled?
(Exact code input/out I don't feel like is necessary, just plug any component into react compiler and take input/output and you should see this being the case).
Everything listed here is a de-optimisation, Specifically the stack vs heap memory is not something iv'e seen discussed. The hope would be that the optimisations out-weigh the de-optimisations. The output looks like it can only EVER produce slower mounts, but may produce faster renders.
How many case studies are like ours where they've noted React compiler actively is making things slower.
Is the 'mount' regression completely intentional and is there a write-up about this somewhere.
Is the react compiler intended to be used in every app? Or just ones where the maintainers are using useCallback / useMemo / memo everywhere (which is always a de-optimisation) and the main benefit is coming from them being able to remove these for the react-compilers faster alternatives?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We finally enabled React compiler on our library; Results were mounts went from 40ms -> 80ms which is a 2x regression. We started to investigate why and what the emission looks like and what our thoughts are this which I wanted to get some advice on:
(Exact code input/out I don't feel like is necessary, just plug any component into react compiler and take input/output and you should see this being the case).
Everything listed here is a de-optimisation, Specifically the stack vs heap memory is not something iv'e seen discussed. The hope would be that the optimisations out-weigh the de-optimisations. The output looks like it can only EVER produce slower mounts, but may produce faster renders.
Beta Was this translation helpful? Give feedback.
All reactions