Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize ngrx/store-devtools #314

Open
btopro opened this issue Feb 25, 2017 · 14 comments
Open

Optimize ngrx/store-devtools #314

btopro opened this issue Feb 25, 2017 · 14 comments

Comments

@btopro
Copy link

btopro commented Feb 25, 2017

@heyMP found an interesting issue the other day. We've built an Angular2 based collaborative one-page app that lets people post images and then comment on them. Nothing crazy. Well, we started to notice if we throw like 100+ objects to present on the UI that the first load is fine, but any change to any object after that causes the app to run horrifically slow to the point of being unusable.

I was told on twitter to post here so not complaining just didn't realize this was what was happening and poor @heyMP refactored our whole app to no avail till he realized it was the plugin.

@zalmoxisus
Copy link
Owner

Thanks for the report. Do you use the extension with Redux as usually or with integrations like ngrx/store, ng2-redux...?

@zalmoxisus
Copy link
Owner

Any details on this? I don't see any leaks on the extension part.

I assume you're using ngrx/store-devtools, which is sending the whole lifted data on every update even when it shouldn't?

@heyMP
Copy link

heyMP commented Feb 27, 2017

Yeah, it's using ngrx/store-devtools. And we are using redux for pretty heavily: routeing, crud http operations, etc. When testing with minimal content, the app works fine, redux devtools time travelling works fine. But when we generate a bulk of content we roughly benchmarked the following:

list of 100 text-based submissions -> navigate to a handful of submissions -> create json export from redux devtools extension
This will result in a file size around 50mb.

Does that sound outlandish of a file size?

@zalmoxisus
Copy link
Owner

zalmoxisus commented Feb 27, 2017

I'm not familiar with ngrx/store-devtools, but @born2net said he solved a similar case by using it as following:

StoreDevtoolsModule.instrumentStore({maxAge: 2}),

However, that can be addressed better on ngrx/store-devtools part to:

  1. not send data when the extension is not opened (react on START / STOP messages received from the extension, and additionally supporting PAUSE_RECORDING action would be useful too).
  2. send the whole lifted state only on START, except that send only the current state and action (send(action, state)).
  3. have a default maxAge value (I'd suggest 50 like we use for Redux) to not allow growing the liftedState infinitely.

Other than that, there's nothing we can do from our part.

\cc @MikeRyan52

@zalmoxisus zalmoxisus changed the title Possible memory leak in large apps? Optimize ngrx/store-devtools Feb 27, 2017
@born2net
Copy link

yes in our very large redux store, changing to StoreDevtoolsModule.instrumentStore({maxAge: 2}), solved it

@heyMP
Copy link

heyMP commented Feb 28, 2017

That definitely helps. Thanks for the help!

@guojenman
Copy link

guojenman commented May 10, 2017

maxAge = 2 makes no difference for me. All I can do for now is to remove it from my production build. I have a very large store and multi-user support, with the server replaying back all actions to all connected clients. With the StoreDevtools, actions start to take 2-4x as long after around 400 actions.

Left it on for my dev build since it's so indispensable :)

@Braincompiler
Copy link

Braincompiler commented Jun 6, 2017

I found out that tryCatchStringify seems to be the bottleneck.
bildschirmfoto 2017-06-06 um 12 46 47

It's part of the redux-devtools' API which is used by @ngrx/store-devtools. With @angular-redux/store there is no problem with devtools cause it's not using the API. There you are integrate the devtools directly.

@zalmoxisus
Copy link
Owner

@Braincompiler of course JSON.stringify, which it invokes, is the bottleneck. What I was suggested above would help not to have so large amount of data to stringify and not invoke the stringify when not necessary, but as written it can be done only from @ngrx/store-devtools part as it sends/receives data to/from the extension. The idea is that a browser extension is in a separate process and you have to stringify the data in order the extension to receive it.

@Braincompiler
Copy link

@zalmoxisus I get the idea, I just wanted to provide the information about what I found out :)

@mightyaleksey
Copy link

mightyaleksey commented Oct 23, 2017

Hi, looks like a faced a similar problem with tryCatchStringify function. In my case we have an array of ~40000 elements in the redux store and JSON.stringify makes store updates slower.

Action and state sanitizers can help a lot here. I made a replacement for the big values before serialization and it resulted in significant performance boost.

@javico2609
Copy link

HI, In my case we have Observable.Websocket that emits several msg per second and the tools freeze complete my browser.

@javico2609
Copy link

there are the way to disabled the DevTools on fly ?

@gionkunz
Copy link

gionkunz commented Nov 7, 2018

Maybe FP structural sharing for storing state history would help solving the memory issues that come with the devtools with large datasets, just throwing in two cents.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants