Immer 7 is 8 times slower than immer 6

[lpatiny]

🐛 Bug Report

We have a (too) complex open source project that allows to display scientific data https://github.com/cheminfo/nmr-displayer

Going from immer 6.0.9 to immer 7.0.9 slow down the vertical scale of spectra (mouse wheel) by a factor 8 !

Link to reproduce

Here are 2 links:

Version build with immer 7.0.9:

https://www.nmrium.org/v0.3.3/#/SamplesDashboard/afp2vszl3kj/cytisine2dhttps:wwwnmriumorgdatacytisine2dhsqcjson?sampleURL=https%3A//www.nmrium.org/samples.json#/

Version build with immer 6.0.9

https://www.nmrium.org/v0.3.5/#/SamplesDashboard/ul8f8s4969/undefinedcytisine2dhttps:wwwnmriumorgdatacytisine2dhmbc-onlyjson?sampleURL=https%3A//www.nmrium.org/samples.json#/

In attachments videos displaying the difference of speed Archive.zip

To Reproduce

Click on the link and you may zoom on this area

Then you may use the scroll button on the mouse to vertically scale the spectrum. You will see that version 6 is 8 times faster than version 7. This can be confirmed in the google chrome performance tab.

Observed behavior

Version 7 is 8 times slower than version 6

Expected behavior

speed should be the same in version 6 and 7

Environment

Google chrome

• Immer version:
• I filed this report against the latest version of Immer

[mweststrate]

Before looking into it, what are the perf differences with 7 if you forcefully enable or disable autoFreeze?

…

On Thu, Oct 8, 2020 at 10:47 AM Luc Patiny ***@***.***> wrote: 🐛 Bug Report We have a (too) complex open source project that allows to display scientific data https://github.com/cheminfo/nmr-displayer Going from immer 6.0.9 to immer 7.0.9 slow down the vertical scale of spectra (mouse wheel) by a factor 8 ! Link to reproduce Here are 2 links: Version build with immer 7.0.9: https://www.nmrium.org/v0.3.3/#/SamplesDashboard/afp2vszl3kj/cytisine2dhttps:wwwnmriumorgdatacytisine2dhsqcjson?sampleURL=https%3A//www.nmrium.org/samples.json#/ <https://www.nmrium.org/v0.3.3/#/SamplesDashboard/afp2vszl3kj/cytisine2dhttps:wwwnmriumorgdatacytisine2dhsqcjson?sampleURL=https%3A//www.nmrium.org/samples.json%23/> Version build with immer 6.0.9 https://www.nmrium.org/v0.3.5/#/SamplesDashboard/ul8f8s4969/undefinedcytisine2dhttps:wwwnmriumorgdatacytisine2dhmbc-onlyjson?sampleURL=https%3A//www.nmrium.org/samples.json#/ <https://www.nmrium.org/v0.3.5/#/SamplesDashboard/ul8f8s4969/undefinedcytisine2dhttps:wwwnmriumorgdatacytisine2dhmbc-onlyjson?sampleURL=https%3A//www.nmrium.org/samples.json%23/> In attachments videos displaying the difference of speed Archive.zip <https://github.com/immerjs/immer/files/5346807/Archive.zip> To Reproduce Click on the link and you may zoom on this area [image: image] <https://user-images.githubusercontent.com/1484241/95442420-a469c080-095b-11eb-90ee-d075c18521d1.png> Then you may use the scroll button on the mouse to vertically scale the spectrum. You will see that version 6 is 8 times faster than version 7. This can be confirmed in the google chrome performance tab. Observed behavior Version 7 is 8 times slower than version 6 Expected behavior speed should be the same in version 6 and 7 Environment Google chrome - *Immer version:* - I filed this report against the *latest* version of Immer — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#681>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBC4HBSNGNPCGEXZSP3SJWDDTANCNFSM4SIQTXNA> .

[lpatiny]

I measured the time using google chrome performance to vertical scale one level

autoFreeze(false);: ~1600 ms

autoFreeze(true): ~220 ms

(there is a branch for testing: https://github.com/cheminfo/nmr-displayer/tree/immer7)

[mweststrate]

Sorry, living out of my mailbox now. For clarification: autoFreeze brings it back to the same perf level, or is that the one that is 8 times slower?

…

On Thu, Oct 8, 2020 at 12:21 PM Luc Patiny ***@***.***> wrote: I measured the time using google chrome performance to vertical scale one level autoFreeze(false);: ~1600 ms [image: image] <https://user-images.githubusercontent.com/1484241/95451971-d7668100-0968-11eb-807e-00a31770bdf6.png> autoFreeze(true): ~220 ms [image: image] <https://user-images.githubusercontent.com/1484241/95451708-79399e00-0968-11eb-95f2-a34d2ab1d807.png> (there is a branch for testing: https://github.com/cheminfo/nmr-displayer/tree/immer7) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#681 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBFCMXT7GYXNXMMMZZLSJWOEJANCNFSM4SIQTXNA> .

[lpatiny]

autoFreeze(true) gives the expected performance, same performance that in the developement mode

When we have autoFreeze(false) we are 8 times slower, the same as with the build application

[mweststrate]

Yeah, that confirms my suspicion; immer 7 takes some additional effort to prune the data for drafts that might be stored somewhere indirectly inside a new objects (so effectively a full depth search for previously unseen data), a case that Immer 6 didn't always handle correctly. For previously frozen data we now for sure it doesn't need pruning, so that is why freeze gives the better results. However, I didn't switch to autoFreeze by default as that would be a breaking change, but probably a new major can be released in a couple of weeks that makes it the default, even for production builds. Calling autoFreeze(true) for now explicitly should also make sure it is frozen by default in prod builds.

…

On Thu, Oct 8, 2020 at 1:56 PM Luc Patiny ***@***.***> wrote: autoFreeze(true) gives the expected performance, same performance that in the developement mode When we have autoFreeze(false) we are 8 times slower, the same as with the build application — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#681 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBEOGAXIA2NPTYWKBD3SJWZJLANCNFSM4SIQTXNA> .

[lpatiny]

Great many thanks. I will implement the autoFreeze(true) in the meantime

[mweststrate]

Reopening temporarily to be able to refer to it in the changelog

[ctrlplusb]

This seems like a big deal, a complete u-turn on previous recommendations / understanding around the performance characteristics of Immer. 😮

Could we consider adding the ability to scope the freeze flag, enabling or disabling it for a particular produce call, rather than toggling it on/off at a global level? At least then each package can make its own decisions around how it wants to optimize around the freezing feature without triggering a global flag that may break the expectations for other modules.

---

Update

Ok, dug into source and noted that the Immer class is being exported, allowing this at an instance level at least.

import { Immer } from 'immer';

const neverAutoFreezeImmer = new Immer({
  useProxies: typeof window !== 'undefined' && typeof window.Proxy !== 'undefined',
  autoFreeze: false,
});

[mweststrate]

Fixed in 8.0.0.

@ctrlplusb note that the u turn is mostly caused by an earlier major release (7 iirc) that changed the performance characteristics, so the new default brings it better in line with how Immer used to behave before.

[ashot]

This doesn't seem like a great fix because it means you can never mutate data outside of a producer for data managed by immer, without taking a huge performance hit (unless I'm missing something).

For some cases its useful to have that escape valve (see "you can always opt out" https://immerjs.github.io/immer/docs/performance#you-can-always-opt-out).

Is having an option to turn off pruning potentially a solution here?

[mweststrate]

No, because that trades correctness for performance and will create an absolute maintenance nightmare. If the perf actually hits you, you can always just write the logic by hand and drop produce in that case altogether.

…

On Wed, 3 Mar 2021, 19:03 Ashot Petrosian, ***@***.***> wrote: This doesn't seem like a great fix because it means you can never mutate data outside of a producer for data managed by immer, without taking a huge performance hit (unless I'm missing something). For some cases its useful to have that escape valve (see "you can always opt out" https://immerjs.github.io/immer/docs/performance#you-can-always-opt-out). Is having an option to turn off pruning potentially a solution here? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#681 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBCU4LMRKU4AFIQVW3LTB2BW7ANCNFSM4SIQTXNA> .

[ashot]

But how can you write the logic by hand if the object is frozen?

[mweststrate]

Like reducers and alike are normally written, by creating new objects for everything you change

…

On Wed, 3 Mar 2021, 19:32 Ashot Petrosian, ***@***.***> wrote: But how can you write the logic by hand if the object is frozen? — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#681 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAN4NBHRKDPJHUCVBDANJVTTB2FDRANCNFSM4SIQTXNA> .