3.0.1
https://jsfiddle.net/james_wasson/2ut7rbx5/
Please refer to the console for more information while running this fiddle.
You can control what is being logged by changing the flags at the top of the fiddle
Depending on Vuex should be of similar speed to passing as props.
Here is an example of passing by props: https://jsfiddle.net/james_wasson/8g2fxr9n/
Depending on the number of rows the removal time increase to more than 100 milliseconds, and at very high numbers of rows (> 400) removal can take up to 500 milliseconds
It seems to only happen when there is interdependence between the getters on the Vuex store and the list being generated.
Something like n! time.
Faster 0-list dependancy in getters example: https://jsfiddle.net/james_wasson/cr4sem3y/
Thank you for reporting the detailed issue!
I've looked into this perf issue. Destroying computed properties (watchers) costs O(n*m) where n is computed property's depending values (on your example, the array and its items), m is all watchers which depends on the values.
I found we can reduce the order to O(n) so just made a PR to Vue repository (Vuex is actually using Vue's reactive system under the hood). https://github.com/vuejs/vue/pull/8944
@ktsn Haha, we've had the exact same thought. Nevertheless, using an object has it's drawbacks, adding large datasets is considerably slower than pushing to array and as is mentioned in the #8157 Object.keys or Object.values is not stable across browsers, which would result in unexpected notification order... As @yyx990803 wrote, the reactivity system should be rewritten to proxies for 3.* we'll have to probably wait until then.
Most helpful comment
@ktsn Haha, we've had the exact same thought. Nevertheless, using an object has it's drawbacks, adding large datasets is considerably slower than pushing to array and as is mentioned in the #8157
Object.keysorObject.valuesis not stable across browsers, which would result in unexpected notification order... As @yyx990803 wrote, the reactivity system should be rewritten to proxies for 3.* we'll have to probably wait until then.