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

Vuex recording performance improvements #546

Closed
yyx990803 opened this issue Jan 23, 2018 · 6 comments
Closed

Vuex recording performance improvements #546

yyx990803 opened this issue Jan 23, 2018 · 6 comments

Comments

@yyx990803
Copy link
Member

yyx990803 commented Jan 23, 2018

Currently the Vuex panel takes a JSON snapshot of the entire store on every mutation, and this can lead to perf problems when the store state is large, or when there are many mutations being committed with short intervals.

Instead of the taking a full snapshot every time, we can:

  • Keep a snapshot of initial state on the app side.
  • Only send the mutations to the devtool side.
  • When a state frame is inspected on the devtool side, send a request to the app side, with the list of mutations committed since the initial state.
  • The app side replays the mutations and send the resolved state back to the devtool side.
  • Resolved state can be cached on the devtool side with an LRU.

This means inspected state snapshots are resolved on demand, and each mutation only sends a payload of the mutation itself, which should be drastically cheaper.

@Akryum
Copy link
Member

Akryum commented Jan 23, 2018

I was also thinking of splitting this snapshot work per modules. That way, we only send module state that changed instead of all the modules every time.

Also, we are currently sending the snapshot for each mutation. We could only send it if the Vuex tab is active.

@Akryum
Copy link
Member

Akryum commented Jan 23, 2018

When a state frame is inspected on the devtool side, send a request to the app side, with the list of mutations committed since the initial state.

We could only send an index there. Then we replay the mutations up to this index and we can cache it to speed up things for next time.

@mcfarljw
Copy link

mcfarljw commented Jan 24, 2018

Do you think it's possible this could be causing the devtools to crash for me every once in a while after prolonged use? I have a large dataset loaded up (~20,000 objects) for a cordova web application. I am using Object.freeze to reduce the memory imprint similar to this thread: vuejs/vue#4384

I've noticed after a number of mutations or webpack reloads it'll crash.

@yyx990803
Copy link
Member Author

@mcfarljw if all that state is stored in Vuex, then it's likely. Try turn off Vuex recording when you don't need it.

@Akryum Akryum changed the title Proposal: Vuex recording performance improvements Vuex recording performance improvements Jan 24, 2018
@heygambo
Copy link

Try turn off Vuex recording when you don't need it.

@yyx990803 is there a programmatic way how to disable it when the app loads? I'd like to disable events and mutations recording by default for my app.

@Frizi
Copy link

Frizi commented Jul 5, 2018

There is clearly a performance problem introduced by copying massive object structures on every mutation, so the main goal would be to get rid of that (at least not do it every frame).

Instead of doing full state snapshots every time, maybe the actual mutated state could be tracked using vue’s reactivity. Extension would then only receive new values of changed fields directly. The full state snapshot could be rebuilt from partial updates in the extension thread, which leaves app responsive and debuggable. Other potential benefit from that would be the ease of implementation of "diff" feature (similar to redux devtools). The incremental mutation changes could be displayed directly to the user. That “diff” view would have a benefit of preserving the intent of a programmer exactly, instead of relying on heuristics to make sensible representation of difference between two big objects.

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

5 participants