Skip to content

Optimize quadratic-time insertion in QSortFilterProxyModel

(cherry picked from commit 7d92ef63)

According to https://codereview.qt-project.org/c/qt/qtbase/+/341365, this commit is present in Qt branches 6.0, 6.1, 6.2. As far as I can tell, it has not been cherry-picked to the proprietary Qt 5.15 branch (though I cannot verify this).

The fix should work well in Qt 5.15 as that is the version I have implemented, tested and benchmarked it on. Originally I proposed to cherry-pick it into Qt 5.12 and 5.15, but reviewers considered this risky:

Christian Ehrlicher: tbh I would not even backport it to 5.15. It worked fine for last 10 years or even more so why is it now so important that it must go into Qt5?

David Faure: I agree. Performance fixes, historically and generically speaking, are a great risk of regressions. (Either regressions in correctness, or regression in performance in a different usage scenario) I vote against a 5.15 backport. Or maybe in 6 months, once we have more experience with the real-world impact of the change :)

After seeing the corresponding benchmark, David Faure decided not to veto a 5.15 backport. But I don't think I can backport to the non-free Qt 5.15 branch. And I only care about the free Qt5PatchCollection anyway. Formally https://community.kde.org/Qt5PatchCollection does not require a commit to be in the proprietary Qt 5.15 branch. But see the relevant Apr 26-27 discussion in comments to https://codereview.qt-project.org/c/qt/qtbase/+/341842.

I just logged the KDevelop bug, which is the original reason for implementing this patch: Bug 439003.

Almost two months have passed since the merge with no report that I know of about a regression caused by this fix. Can this patch be cherry-picked into Qt5PatchCollection despite most likely not being included in the proprietary 5.15 branch? Are more benchmarks necessary to increase confidence in the absence of performance regressions?

Merge request reports