clearing search bar with a large database is slow

Bug #1635087 reported by Be
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Mixxx
Fix Released
Medium
Unassigned

Bug Description

From http://www.mixxx.org/forums/viewtopic.php?p=29623#p29623:
"I've learned to NEVER click the X button in the library search. It wants to re-sort the world every time. I give the field focus, hit ctrl-A to select all the text, and start typing."

Confirmed by another user here: http://mixxx.org/forums/viewtopic.php?p=30520#p30520

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Looks like clearing via the X is equivalent to changing the search query 5 times:

Debug [Main]: WSearchLineEdit::onSearchTextCleared
Debug [Main]: WSearchLineEdit::slotTextChanged ""
Debug [Main]: WSearchLineEdit::triggerSearch ""
Debug [Main]: LibraryTableModel(0x7fafcfbf9600) select() took 2 ms 293
Debug [Main]: LibraryTableModel(0x7fafcfbf9600) select() took 2 ms 293
Debug [Main]: LibraryTableModel(0x7fafcfbf9600) select() took 2 ms 293
Debug [Main]: WSearchLineEdit::triggerSearch ""
Debug [Main]: LibraryTableModel(0x7fafcfbf9600) select() took 3 ms 293
Debug [Main]: LibraryTableModel(0x7fafcfbf9600) select() took 3 ms 293

Other than a few minor differences the code paths are identical (e.g. restoring the vertical bar position) so we can probably fix this by making it search for "" just once.

Odd that the workaround works, because it's functionally equivalent except for:

- QLineEdit::clear()

- WTrackTableView::restoreVScrollVarPosition() [1]

Compare the WTrackTableView::onSearchCleared vs. WTrackTableView::onSearch

-

[1] https://github.com/mixxxdj/mixxx/blob/master/src/widget/wtracktableview.cpp#L981

Revision history for this message
RJ Skerry-Ryan (rryan) wrote :

Oops, everything from "Odd that the workaround works, because it's functionally equivalent except for:" and below was an old draft.

Changed in mixxx:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

Instead of immediately triggering a search that returns all tracks of the (probably huge) library the debouncing timer should be engaged when clearing the search edit. This is an easy fix and would establish a consistent behaviour.

Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :
Changed in mixxx:
assignee: nobody → Uwe Klotz (uklotzde)
milestone: none → 2.1.6
Changed in mixxx:
status: Confirmed → In Progress
Revision history for this message
Daniel Schürmann (daschuer) wrote :

The PR cann't fix the route cause of this bug. But it is also not the right bug to track the root cause so let's close it.

Changed in mixxx:
status: In Progress → Fix Committed
Revision history for this message
Uwe Klotz (uklotzde-deactivatedaccount) wrote :

Of course, it doesn't fix the bug. It just establishes a consistent behaviour. With the configurable debouncing timeout in 2.2 it actually becomes useful.

Clearing the box without starting the debouncing timer is not an option, because then the contents of the view might stay inconsistent forever.

The issue will finally be resolved once we no longer fetch the whole result set eagerly from the database.

Changed in mixxx:
status: Fix Committed → Fix Released
Revision history for this message
Swiftb0y (swiftb0y) wrote :

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/8665

lock status: Metadata changes locked and limited to project staff
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.