Repository navigation
PERF Call KDTree in mutual_info to reduce memory footprint - #17878
Conversation
|
Thank you @noelano Please add an |
thomasjpfan
left a comment
There was a problem hiding this comment.
Not blocking thought: I wonder if this metric can take advantage of n_jobs + chunking with a threading backend.
Thank you for the PR @noelano! LGTM
Co-authored-by: Thomas J. Fan <[email protected]>
|
I applied suggestions, but now I see that we still need to have the "what's new" entry to merge.
We could investigate, but maybe let's merge this PR first.. @noelano Would you have benchmark results before/after this change? |
…t-learn into mutual_info_kdtree
|
|
||
| - |Efficiency| Reduce memory footprint in :func:`feature_selection._compute_mi_cd` | ||
| and :func:`feature_selection._compute_mi_cc` by calling :class:`neighbors.KDTree` | ||
| for counting nearest neighbors |
There was a problem hiding this comment.
| for counting nearest neighbors | |
| for counting nearest neighbors. |
|
In terms of benchmark I can't share the data I was using to test but here's a quick illustration with 1m points using memory_profiler: before: 152.3 MiB 0.0 MiB nn.set_params(algorithm='kd_tree') after: Execution time is slight improvement also gives In terms of n_jobs and chunking I hadn't looked into it since the public functions don't expose those anyway. I guess it'd be a separate task to look into adding that as an enhancement |
Co-authored-by: Thomas J. Fan <[email protected]>
| - |Efficiency| Reduce memory footprint in :func:`feature_selection.mutual_info_classif` | ||
| and :func:`feature_selection.mutual_info_regression` by calling :class:`neighbors.KDTree` | ||
| for counting nearest neighbors |
There was a problem hiding this comment.
May need to rewrap to make this pass linting.
|
Thank you for the benchmark!
This PR should not consider chunking. It was a passing thought when reviewing the code. |
|
Thank you @noelano and reviewers! |
…arn#17878) Co-authored-by: Thomas J. Fan <[email protected]>
What does this implement/fix? Explain your changes.
The mutual_info functions can end up requiring high amounts of memory which makes it particularly tricky to perform multiple MI computations for features in parallel.
The biggest impact is the
nn.radius_neighbourscall which loads the full nested arrays of all neighbours into memory before getting their sizes.Since the algorithm is already being set to
kd_treeanyway we can explicity call the KDTree class in order to use thequery_radiusmethod to get the count of neighbours without having to first store them.