Performance Improvements

[snewcomer]

Hey Toran! Looking at some perf issues related to filtersMap. Could an API be exposed for us to clear filtersMap, but keep the array and identityMap around? Basically, for every push of a location, it will look at source and call updateFilters and updateContent on each location. So if in a grid view, the location array gets larger and larger, and there is a filterFunc that looks at location (in many to many situations there is a filterFunc that looks at location for its id to see if it is in the join model), that filter set gets more expensive.

The reason to clear out filtersMap and not just use store.clear is b/c for types such as location-status that might be bootstrapped, we might want to clear the filtersMap, but not clear the locale cache of those objects.

[snewcomer]

The above would allow manual management of a performance problem that we are seeing. If we click on 15 pages of a grid view in a rolw, the response eventually turns from ~1s to about ~2 or 3s, and this is due to the filtersMap having to call updateContent for each location in the store when 1 location is pushed in. I could spike out a function and related tests for you if you would like.

[toranb]

Great question but honestly I'm not sure it's that simple. Imagine this scenario (assuming this is the setup you are about to implement to fix the perf issue)

1. visit a few pages in the grid, things slow down
2. you decide to wipe out the filtersMap for location
3. suddenly any other component or model that used the filterMap (above) to return locations is no longer observed (including any relationship mapping)

The only part of my apps where I've found "removing" a filterMap was a good idea is when you fetch it in a route and pass it down to the controller/component. In that case you could "throw out" the filterMap (array proxy) when you leave that route because you know for sure the component that used it was also destroyed. (example here from the tests in simple-store)

https://github.com/toranb/ember-cli-simple-store/blob/master/tests/dummy/app/routes/filters.js#L42-L49

In your situation I'd say you have 3 options

1. avoid pushing location data in when you fetch new grid data (avoids the push for location so you don't need to recompute the filterMap for it)
2. cut the relationship abstraction so you don't pay this recompute tax but still get "up to date" location data for the grid if that is shown
3. use a different singleton store for the grid so you can "clear" filterMap and not break the relationship observation in the models used across the system for other components/m2m relationships