-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Default filterHandler is inefficient #989
Comments
That makes sense. Someone must have thought that filters were cumulative at some point. Please try it out and run the test suite. Hopefully that will catch any issues. The suite is extensive but never complete. Related: #478, not using range filters is also shredding crossfilter performance. |
Digging in a little now. Hopefully I can move to using filterExact or filterRange when appropriate as well. |
BTW - which branch should I send a pull request against? |
Thanks @esjewett, for straight bug fixes it's master/2.0. This doesn't present any interface changes, and I don't think it's very risky because any problems will be easy to detect. |
For some reason the filterRange part of this fails tests, but can't see why. I will submit a pull request with just the removal of the extra null filter and the filterExact part.
|
woof, that is some complicated logic in that case, i am not surprised. thanks for noting it. |
I had also tried adding a isRangedFilter property to the range array returned by dc.filters.RangedFilter (property value was just JS true) and then testing on that. But that never seemed to test as true. I wonder if unexpected properties are stripped somewhere. Will look at it further at some point! |
Yeah, I'm adding a |
Ah, the filterType is great, actually. In my WebWorker thing I do serialize filters. It's not a problem right now because all my filters are either exact values or ranges, but when I make things more general it will become an issue. |
Fixed in 2.0 beta 19 |
This is the default filterHandler in the base mixin:
Every time a filter is applied to a chart, the current filter on the dimension is removed and then a new one is added. This is extremely inefficient. I believe it renders all of the benefit of Crossfilter's optimization for incremental filter change moot. Instead, the filter should be removed or a new filterFunction should be applied. Depending on the filter type, we could even optimize further and use dimension.rangeFilter or dimension.exactFilter.
Can we start by removing the first line where
dimension.filter(null);
or is this doing something somewhere that I don't understand?The text was updated successfully, but these errors were encountered: