Skip to content

UnitSelectionSorting improvements: remove lexsort, fix bug, save memory by sharing parent cache when possible - #4783

Open
grahamfindlay wants to merge 5 commits into
SpikeInterface:mainfrom
grahamfindlay:fix/units-selection-lexsort
Open

grahamfindlay wants to merge 5 commits into
SpikeInterface:mainfrom
grahamfindlay:fix/units-selection-lexsort

Conversation

@grahamfindlay

Copy link
Copy Markdown
Collaborator

Follows #4606, #4581, #4618, #4695. Just copying my commit messages here:

Commit 1

Per #4606 and #4618, full lexsort is no longer needed (it is ordered
going into remap_unit_indices_in_vector, and that function can't mess up
the ordering).

This also fixes a bug where SortingAnalyzer.select_units with
reordered units was incorrectly lexsorting the new sorting's spike
vector, permuting cotemporal spikes into unit-ascending order, while
extensions sliced its per-spike data (e.g. amplitudes, locations, etc.)
with a mask over the old (i.e. unpermuted) spike vector, causing a
discrepancy in ordering where row i of the extension data didn't match
row i of the new (permuted) spike vector.

There were warnings about this already in the code:

# TODO check that unit_ids are in same order otherwise many extension do handle it properly!!!!

(although to be clear, the cause of the problem here wasn't on the
extension side, but on the Sorting side).

test_selection_preserves_parent_orderand
test_select_units_reordered_keeps_extension_alignment (sorry for this
name, open to suggestions) should hopefully prevent this from happening
again.

Commit 2

UnitSelectionSorting shares the parent's spike vector cache(s) on
identity selections (including rename).

Can save many GBs of memory. This also keeps a lazy Zarr spike vector
lazy (#4623 ).

analyer bug

Per SpikeInterface#4606 and SpikeInterface#4618, full lexsort is no longer needed (it is ordered
going into remap_unit_indices_in_vector, and that function can't mess up
the ordering).

This also fixes a bug where `SortingAnalyzer.select_units` with
reordered units was incorrectly lexsorting the new sorting's spike
vector, permuting cotemporal spikes into unit-ascending order, while
extensions sliced its per-spike data (e.g. amplitudes, locations, etc.)
with a mask over the old (i.e. unpermuted) spike vector, causing a
discrepancy in ordering where row i of the extension data didn't match
row i of the new (permuted) spike vector.

There were warnings about this already in the code:
```
```
(although to be clear, the cause of the problem here wasn't on the
extension side, but on the Sorting side).

`test_selection_preserves_parent_order`and
`test_select_units_reordered_keeps_extension_alignment` (sorry for this
name, open to suggestions) should hopefully prevent this from happening
again.
identity selections (including rename).

Can save many GBs of memory. This also keeps a lazy Zarr spike vector
lazy (SpikeInterface#4623).
@alejoe91 alejoe91 added performance Performance issues/improvements core Changes to core module labels Sep 22, 2026
@alejoe91 alejoe91 added this to the 0.105.1 milestone Sep 28, 2026
Comment thread src/spikeinterface/core/tests/test_sortinganalyzer.py
grahamfindlay and others added 3 commits October 5, 2026 11:53
Add helpful comment suggested by Alessio.

Co-authored-by: Alessio Buccino <alejoe9187@gmail.com>
@samuelgarcia

Copy link
Copy Markdown
Member

Hi Graham.
Thank you for this.

There is a small issue to be discuss for the commit 2. This prevent the sorting parent to be garbage collected by the run time. And if the sorting object belong to an analyzer maybe the analyzer itself will not disappear from the memory because they will share the same spike buffer unfer the hood.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

core Changes to core module performance Performance issues/improvements

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants