lp1845837: Speed up purging of tracks #2393
Conversation
|
This looks like a fairly small change. Should we target it for the 2.2 branch? |
|
I have backported the changes to 2.2. The merge conflicts seem to be manageable. Let's give it a try... More merge conflicts need to be resolved when porting to master. |
|
The Travis CI build failures on macOS are unrelated. |
|
Includes #2396 |
| } | ||
|
|
||
| void PlaylistDAO::removeTracksFromPlaylist(const int playlistId, QList<int>& positions) { | ||
| void PlaylistDAO::removeTracksFromPlaylist(int playlistId, QList<int> positions) { |
There was a problem hiding this comment.
Why not const QList& ? A copy by value increases the shared counter, which requires qt:as_const() in range based loops to be efficient.
There was a problem hiding this comment.
Because a local, writable copy is need for sorting. First line of the function body.
There was a problem hiding this comment.
The QList is actually not shared, but moved into this function. The caller never accesses it again after calling the function. The copy happens, because instead of move semantics Qt relies on implicit sharing.
I could add a std::move at the caller's site, because QList has a move constructor. This should eliminate the temporary copy.
There was a problem hiding this comment.
Ah I see, thank you for explaining.
There was a problem hiding this comment.
I omitted to use std::move in the first place because I was recently told not to use it in Qt code ;) What I definitely won't do is checking each and every Qt class before using it. I prefer to use it if it is semantically correct, whether it is supported or not.
|
All issues addressed. |
|
Thank you. LGTM |
https://bugs.launchpad.net/mixxx/+bug/1845837
This feature is almost unusable in its current state! Now only a single signal for multiple playlists is send after purging multiple tracks from multiple playlists.