Investigate optimizations for immutable invariant middleware

[markerikson]

The immutable invariant middleware is relatively slow, because it does deep checks on the whole state, and uses recursion.

I wonder if we'd be able to speed it up by:

• Converting the recursion to some sort of a loop with a queue
• Skipping certain items if they're already frozen

Granted, this only affects dev mode and not prod, but if we can speed it up a bit that would be a net win.

There are some other mutation detection options out there that involve proxies, like https://www.npmjs.com/package/mutation-sentinel and https://www.npmjs.com/package/will-mutate , but not sure if those approaches would work sufficiently for our use case.

[markerikson]

So last night I kinda hacked together an alternate implementation of the track and detectMutations functions based on a queue.

It also seems, at first glance, to be 10x slower than the existing implementation :) I'll have to play around with it further and figure out why.

[markerikson]

For posterity: the queue approach I wrote just turned out to be drastically slower. Weirdly, after doing some performance profiling, the biggest hotspots appeared to be, uh... inserting a new field into a cache object and reading it out again later? Still no idea how that's so slow, unless it had to do with resizing the internal representation of the object to hold around 90000 keys.

That said, the huge win for optimizing the original algorithm was treating frozen values as immutable, which lets us almost always bail out after just skimming past the top level values of the root state. Additionally, switching from keypath arrays (with lots of .concat() and .join() calls) to just pre-calculated dotted strings was another big perf win.

[codenickycode]

Hi Mark, Sorry I'm late posting this as a stress test related to this thread. Hope it helps if you still need it:

https://sequencer64.com
https://github.com/drumnickydrum/sequencer64

(You requested in https://stackoverflow.com/questions/66781880/redux-toolkit-thunk-disappears-after-getdefaultmiddlware-config )

[markerikson]

@drumnickydrum oh hey, I saw you post this to HN earlier today - looks really neat!

The RTK 1.5.1 release should have drastically sped up the immutability checks - we assume things are fine if objects are frozen and don't recurse further, and also optimized some string usages.

It looks like your project is in fact on RTK 1.5.1. Could you do me a favor and try turning those dev checks back on to see how it performs in dev? My guess is you should see almost no noticeable slowdown with those enabled.

Also, would love to hear any thoughts you have in general on using RTK overall, and especially in a project like this.

[codenickycode]

You're right. It's just as snappy now with the checks on. RTK is great. I made heavy use of createSlice and the built-in thunk support. Writing mutative code in the reducers was a nice bonus. I don't have much experience, so I'm not sure what a normal Redux workflow is like without RTK, but this worked really well for my app. Thx for your work, Nick

…

On Tue, May 11, 2021 at 10:27 PM Mark Erikson ***@***.***> wrote: @drumnickydrum <https://github.com/drumnickydrum> oh hey, I saw you post this to HN earlier today - looks really neat! The RTK 1.5.1 release *should* have drastically sped up the immutability checks - we assume things are fine if objects are frozen and don't recurse further, and also optimized some string usages. It looks like your project is in fact on RTK 1.5.1. Could you do me a favor and try turning those dev checks back on to see how it performs in dev? My guess is you *should* see almost no noticeable slowdown with those enabled. Also, would love to hear any thoughts you have in general on using RTK overall, and especially in a project like this. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#926 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGD3BRQVHRXDQNFUTGWSV73TNHRPNANCNFSM4ZHFI5DA> .