I've been experiencing some issues after the latest update (2.17.0).
When i have the extension closed i can cycle through my app smoothly.
However, when i have the redux-devtools extension open everything gets painfully slow, sometimes even freezing the whole page and forcing me to refresh with the extension closed.
Besides that, when i decide it is worth to open to extension to troubleshoot something, sometimes my app's instance does not appear in the instance selector.
Is anyone else experiencing this since the latest update?
Kudos for the awesome extension =D
Edit: To make it clear: No, i was not experiencing this with the prior version.
@joaotonial last versions should be much faster as I made serialization faster and it's not serializing as much as before. The problem could be that before you were not getting all the data to the extension as it was blocked by the Chrome message limit, which was fixed in https://github.com/zalmoxisus/redux-devtools-extension/pull/582. If that's the case, then you should have this warning in the console:
Application state or actions payloads are too large making Redux DevTools serialization slow and consuming a lot of memory. See https://git.io/fpcP5 on how to configure it.
In that case before you were getting not all actions (if any at all) after reaching that message limit. See #566.
You can try to downgrade to 2.15.5 (here's how to install).
It's planned for 3.0 to offer an option to use the extension from client side (instead of Chrome devtools panel), so there will be no need for serialization and should have no performance cost.
Could this message be due to a possible issue in my code or only the cost of running the extension as a devtool?
Application state or actions payloads are too large making Redux DevTools serialization slow and consuming a lot of memory. See https://git.io/fpcP5 on how to configure it.
@zalmoxisus Is 2.15.5 the correct version to revert back to? After doing so, I still see the Application state or actions... message and experience the same freezing behavior. Would desperately like to get back to a version that doesn't freeze on large payloads. I'm not entirely convinced I was missing messages back then either. At least I never experienced that while debugging with the extension (which I do often).
Love the project, developing without it (since freezing version shipped) has been painful. Please let me know if there's anything else I can do to help. Unfortunately, as far as code examples go, will be quite difficult to recreate the scenario I'm in (large private application).
Thanks!
@joaotonial yes, that confirms that the problem is with huge lifted state, which will reach chrome ram limit for the extensions and crashing after that. Current workaround is to use actionSanitizer / stateSanitizer. The plan is to offer a way to inject everything in client apps process (alternatively for running extension from devpanel), so we'd not have to serialize and duplicate the history, also as it won't be in extension's process there will be no RAM limit.
@barberdt yes, the message was introduced in 2.15.5, but splitting messages to work around chrome limitation was introduced in 2.16. Not much was added till then. Only updating jsan was about serialization, but there shouldn't be anything substantially. I made a build with downgraded jsan to 3.1.10 (including subdependences, like it was till version 2.15.4 of the extension), also removed uglifying and added source maps for debugging (splitting messages is still there though): extension.zip
And here's another build with also reverted #582: extension.zip
Same issue even with extension downgraded to 2.15.5/.6
Any solution? I don't think this problem is project based - didn't touch anything related to reducers since ages - it just hangs after extension update.
@Shiv7n did you try those 2 builds I uploaded above? Here's how to install.
@zalmoxisus i've installed both builds and the problem persists.
I did a hard reset to 2.15.3 tag and uploaded the build there now. It includes commits since July 19 only. Let me know if it works better, so we'd know for sure if it's related to the latest changes.
@zalmoxisus Just tested the 2.15.3 build. Same issue. Maybe just an anomaly, but I did get about 10 seconds or so of interactivity before freezing this time though. In the latest build, freezing happens pretty instantly. 🤷♂️
Thanks for the attentiveness to this. Appreciate it a lot. Happy to test anything you throw my way.
@zalmoxisus still the same. @barberdt i've tested it both on Linux (ubuntu and arch) and windows and got the same results, so probably this issue is not platform based.
Looking at memory usage i've noticed a great rise in consumption.
Result of $ free -m during a heavy state lifting process while extension open:
Start of task:
| total | used | free |shared| buff/cache | available |
| :-----: | :---------: | :-----: | :--------: | :--------: | :--------: |
| 11879 | 5495 | 3161 | 1074 |3222|4992|
End of task:
| total | used | free |shared| buff/cache | available |
| :-----: | :---------: | :-----: | :--------: | :--------: | :--------: |
| 11879 | 8064 | 221 | 1063 |3593|2434|
Obs: there is no noticeable change in ram usage when running the same task with the extension closed.
Thanks for the investigation! Might be some changes in Chrome 70-71 introduced some perf issues. However serialization of large data was an issue since the beginning.
I'll work on a way to run it inside the app's process, so there will be no need for serializing the lifted state.
Another approach would be to send only the necessary part of state history to the extension. It would request only selected state from history for State tab or last two in case of Diff. That would require a complete refactoring of how Inspector Monitor works, and we should remove Log Monitor as it shows everything at once. It would help with states, but there could still be issues if there's large data in actions payloads, we still need to send them all.
I noticed freezing starting yesterday for one angular project I am using it on.
Also on another app (very basic app from Todd Motto's Ultimate NGRX course), while the redux extension will detect my store but do absolutely nothing else. It shows absolutely no data regarding my app at all. Every tab is empty. Most of the buttons in the bottom toolbar do nothing now.
I'm running Chrome 71 on MacOS Mojave.
@zalmoxisus i have an issue that is very similar to the one reported here. After my app becoming slow, the devtools extension freezes and eventually crashes.
I do get this message:
Application state or actions payloads are too large making Redux DevTools serialization slow and consuming a lot of memory. See https://git.io/fpcP5 on how to configure it.
However, my redux state is rather small and I'm not aware of any 'large' payloads I'm sending via actions. The largest payload currently is an array with 3 objects that all contain around 10 fields, which shouldn't be too large in my opinion.
So currently it is unclear for me why the 'payload too large' message is shown and where to fix it. I tried sanitizing of the actions, but it didn't solve anything as the message kept showing.
Do you have any recommendations or things to inspect to find out where the problem might be? Thanks in advance and keep up the good work with this extension!
@oberlage the payload became large during serialization because of the links there to other objects like dom, window, react components, events... So you should sanitize that part as you usually don't need to view it in the extension, it's just creating serialization issues. There's an example on how to sanitize additional data from ui-router that might help.
@zalmoxisus thanks for your help, will do this. My issue seems (indeed) to be related to the ui-router, so the example is very helpful!
i am having the same problem, the page freezes after the first load, then crashes
my state is simple
Chrome Version 72.0.3626.109 (Official Build) (64-bit)
Store Dev-Tools 2.17.0
Confirmed, I have the same problem from last update when I have tried to reload the extension when Chrome get crashed and the Devtools Redux tab is just a blank page now.
Note: clicking in the Redux icon on top is also slow.
OS: macOS Mojave
Version: 2.17.0
Chrome Version: 72.0.3626.119 (Official Build) (64-bit)
Using Firefox works as usual.
Version: 2.17.1
Firefox Quantum: 65.0 (64-bit)
Investigation a bit more about it, in my case it was my own issue regarding to https://github.com/ngrx/platform/issues/537. Now my states are displaying as usual.
I'm using Chrome 72 and Redux DevTools 2.17.0.
I am having the same problem, the page freezes after the first load, then crashes.
Store Dev-Tools 2.17.0
Chrome Version 81.0.4044.129 (Official Build) (64-bit)
Also tried on Firefox 76.0.1 (64-bit) and same problem.
I tried using the sanitizers as detailed in https://github.com/zalmoxisus/redux-devtools-extension/issues/455, but still same issue.
FYI: My code base is open-source (though it is rather large) but happy to provide details if you want to examine a production code base.
Most helpful comment
Thanks for the investigation! Might be some changes in Chrome 70-71 introduced some perf issues. However serialization of large data was an issue since the beginning.
I'll work on a way to run it inside the app's process, so there will be no need for serializing the lifted state.
Another approach would be to send only the necessary part of state history to the extension. It would request only selected state from history for State tab or last two in case of Diff. That would require a complete refactoring of how Inspector Monitor works, and we should remove Log Monitor as it shows everything at once. It would help with states, but there could still be issues if there's large data in actions payloads, we still need to send them all.