Question

I have a reimplemented QSortFilterProxyModel acceptRows to achieve custom behavior, i want it to not filter out items which have a valid child.

class KSortFilterProxyModel(QSortFilterProxyModel):
    #FIXME: Funciona pero es endemoniadamente lento
    def __init__(self, parent=None):
        super(KSortFilterProxyModel, self).__init__(parent)
        self.__showAllChildren = False

    def showAllChildren(self):
        return self.__showAllChildren;

    def setShowAllChildren(self, showAllChildren):
        if showAllChildren == self.__showAllChildren:
            return
        self.__showAllChildren = showAllChildren
        self.invalidateFilter()

    def filterAcceptsRow (self, source_row, source_parent ):
        if self.filterRegExp() == "" :
            return True #Shortcut for common case

        if  super(KSortFilterProxyModel, self).filterAcceptsRow( source_row, source_parent) :
            return True

        #one of our children might be accepted, so accept this row if one of our children are accepted.
        source_index = self.sourceModel().index(source_row, 0, source_parent)
        for i in range( self.sourceModel().rowCount(source_index)):
            if self.filterAcceptsRow(i, source_index):
                return True

        return False

However this aproach doesn’t seems to be efficient because with 300 items it takes almost 3 seconds to update the view, i want to know if theres a better way of doing it.

PD: This class is basically a translation of a KSysGuard one i found in KDE websvn

Answer 1

I don’t see anything obviously wrong with what you’re doing. Keep in mind that filterAcceptsRow is called for every item in your model, and this is of course going to be sluggish because the overhead of calling a Python function from C++ is a few milliseconds. This adds up rather quickly if you have a model with a few hundred items. Add to this the amount of C++ functions called from Python, and you can easily end up with the 3 seconds you’re noticing.

Also, QTableView and QSortFilterProxyModel do an awful lot of clever things to keep the signals they emit and the amount of updates required to a minimum. Sadly, this leads to very bad performance if the rows that are removed or added after a filter reset are very much scattered over your model.

In our projects, we have made the decision to implement most of these item-based models in C++, at least for those methods that are called for every item in a model that contains more than a trivial amount of rows or columns. However, this may not be the answer you’re looking for, especially if your update delays are caused by e.g. other signal handlers connected to the same model. Emitting a signal is usually the same as calling a method.

In short, you’d best use a profiler to see where your application is spending most of its time, and use C++ if it is in these methods that are called once (or even more than once) per item in your model.