[РЕШЕНО] поиск по QSortFilterProxyModel (скорость контейнеров)

[unkeep]

Салют.

Есть прокся  (::QSortFilterProxyModel). В ней надо сделать поиск. Требуется выделить ячейку, удовлетворяющую условию, а также двигаться по результатам поиска вперёд\назад.

Делал двумя способами:
1)  переопределял Data. В ней при Qt::BackgroundRole проверялось условие и возвращался цвет. Это для отображения. Для навигации отдельно пробегался по всему дереву, и записывал индексы в список. (выходит дважды проверяю каждый элемент)
2) Пробегался по дереву и записывал нужные индексы в список. В Data при Qt::BackgroundRole проверял, есть ли индекс в списке.
Оба метода не устраивают. 2ой медленно, 1ый чуть быстрее, но не красиво.

setData(childIndex,Qt::yellow,Qt::BackgroundRole) никуда ничего не записывает. А должна ли?
может делегаты использовать?
как эффективней и правильней будет?

[mutineer]

Второй медленнее, чем первый? значит неэффективно список сделан

[unkeep]

Второй медленнее, чем первый? значит неэффективно список сделан

я его не делал, QModelIndexList использовал. Медленнее потому что при каждом поиске индекса в списке

Код

C++ (Qt)
if (_searchResults->contains(index))  
    return Qt::yellow;
 

нужно сравнивать текущий индекс с каждый индексом  из списка.
На много быстрее оказалось ещё раз проверить  условие:

Код

C++ (Qt)
if (data(index).toString(). contains(searchStr))  
    return Qt::yellow;
 

но как-то не правильно смешивать поиск и представление...

[kambala]

храни результаты в QSet — поиск должен быть быстрее

[unkeep]

храни результаты в QSet — поиск должен быть быстрее

да, в самом меделе быстрее.

только вот не упорядоченный он((

It stores values in an unspecified order

может тогда связку QSet + QList ? для поиска индекса в результатах пользоваться QSet, для навигации по результатам QList?

[kambala]

std::set тогда

[unkeep]

замерил оба способа: QSet + QModelIndexList vs std::set
std::set на 4% медленнее. Так как большой разницы нет, отдаю предпочтение Qtшным контейнерам, чтобы в одном "стиле" всё было