Immer.js performance #613
Dassderdie
started this conversation in
Ideas
Replies: 1 comment
-
|
hi @Dassderdie , thanks for your attention to Mutative. Currently, Mutative has released its latest version 1.0.11. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
TLDR:
I did a little experiment + benchmarks and wanted to share the results just FYI. Because of the FYI character of this, I created a discussion instead of an issue.
We could improve the performance of all our reducers by 3 to 4 times by just switching libraries.
Intro
Immer.js is the library on which all our reducers rely.
Its
produce-method "converts" mutable reducers (the input value is mutated) into immutable ones (the input values are not mutated, and instead, a new copy with the changes is returned).One alternative to
immer.jsis mutative. It has fewer features and bit different names, but aims to be more performant than immer.js.Setup
I replaced
producefrom immer withcreatefrom mutable (d8d3869 and 02e3ac8). This was basically a drop-in replacement, as we didn't use any of the advanced features of immer.Test Setup:
Results:
Detailed outputs
immerjs
Mutative
Mutative without `autoFreeze`
Summary
AddLogEntryActionis not deterministic #580. The migrations are allowed to not be deterministic.autoFreezeas it uses this as an internal flag to determine wether something can be shallow copied or must be deep copied (big perfromance drop when disabling it).The accumulated time for each action per type of action is shown in the tables below.
workshop-babz-großes-szenario
immerjsin msmutativein msmutativenofreezein msworkshop-malteser-großes-szenario
immerjsin msmutativein msmutativenofreezein msThe
[Exercise] Tick-action changes in every patient at least one property (health). In contrast, all other actions change only one property of one patient/personnel/material and potentially some stuff in the R-Trees.Total accumulated time to process all actions
For runtime performance (on the server and client) the
newImmerDraft-benchmark is relevant.The
noImmerDraft-benchmark is the baseline, without any overhead for mutability. It is impossible for thenewImmerDraft-benchmark to be faster than thenoImmerDraft-benchmark.immerjsin msmutativein msmutativenofreezein msAutoFreeze
Disabling
autoFreezereduced the time for each action slightly. Though, the total accumulated time increased slightly. This is very strange.The time needed to freeze every action and the state after receiving it via the WebSocket was not included in this benchmark. In addition, it could be that V8 has (or will have) optimizations for frozen objects (saving memory, heuristics, ...), which would only be relevant when accessing the properties in the actual application on the frontend.
Conclusion
One can see that
mutativeis always between 3 to 4 times faster thanimmer.js.This is basically free performance.
Still, I would recommend using
immer.jsfor now as it is more mature, and we don't need the performance yet.In addition,
mutativecould also probably prevent #531 (if this should ever be desired).immer.jsalso has some performance improvements in the making immerjs/immer#1015, immerjs/immer#941.Beta Was this translation helpful? Give feedback.
All reactions