Performance QTreeView

[dermm13]

Hallo zusammen,

ich fülle eine QTreeView wie folgt:
...

Code: Alles auswählen

_proxyModel = new QSortFilterProxyModel(this);
_proxyModel->setSortCaseSensitivity(Qt::CaseInsensitive);
   
QStringList header = QtPerformance::getTableHeader();
   
QStandardItemModel* model = new QStandardItemModel(0, header.count());
   
for (int col = 0; col<header.count(); col++)
   model->setHeaderData(col, Qt::Horizontal, header.at(col));
   
 QStandardItem* item;
 for (int row = 0; row<10000; row++)
 {
      QList<QStandardItem*> itemList;

      for (int col = 0; col<header.count(); col++)
      {
         item = new QStandardItem(QString("%1 %2").arg(row).arg(col));
         item->data();
         itemList.append(item);
      }     

      model->appendRow(itemList);      
   }

   _proxyModel->setSourceModel(model);
   view->setModel(_proxyModel);

...
Alles schön und gut... Wie kann ich die Performance verbessern?

Danke!

[RHBaum]

Statt den Itembasierten view, den modelbasierten view verwenden und das Model "gescheit" implementieren.
10000 TrieviewObjecte(Grafische Objecte) in nem View wo nur 20-50 angezeigt werden, iss halt ned so intelligent.

Siehe Doku zu Model View Controller-Konzept in der Qt - Doku

Ciao ...

[dermm13]

Ok, eine modelbasierte View ist natürlich auch möglich. Dies bringt aber keinen Performance-Gewinn. Die itembasierte View ist geschickt um Formatierungen durchzuführen.

Code: Alles auswählen

item->setForeground(color);
item->setTextAlignment(Qt::AlignRight | Qt::AlignVCenter);
...

…
Dies ist bei mir der Fall.

Was heißt "gscheit" implementieren? Es ging mir darum, viele Daten zu erzeugen. Außerdem muss sortieren/filtern möglich sein.

[RHBaum]

gescheit in Bezug auf:
Nur das generieren, was auch wirklich benotigt wird ...

Ich wette Du generiest alle ModelItems sofort, am besten noch mit nem "new". Dann brauchst dich auch ned wundern, warum die verwaltung ordentlich performance kostet.

Es ging mir darum, viele Daten zu erzeugen.

Besser, die Daten so organsieren, das sie nicht aufs mal brauchst ....
Sortieren filtern nicht auf ModelItemEbene sondern am besten auf datenstrukturebene.
Und z.B. 5 Millionen Texte sortieren z.b. dauert halt, das wird man nicht wegoptimieren koennen.
Besser: dafuer zu sorgen das man es nur einmal macht ...
noch Besser: man macht es zu einem Zeitpunkt wo es nicht weh tut (beim einfuegen z.b. ) wenn möglich natuerlich.

Die itembasierte View ist geschickt um Formatierungen durchzuführen.

geht mit dem Modelbasierendem aber auch.
Schau dir mal den Qt::DisplayRole enum an.
Das Modelbasierende iss aber imho das designtechnisch bessere, weil es Dir ein konzept und eine Schnittschnelle vorschreibt.
Performancetechnisch besser koenntest schon mit nem Itembasierenden besser fahren, aber nur wenn das verhalten auf deine Anforderung optimieren kannst.
Dazu musst Du aber ueberhaupt erst mal optimieren (in deinem beispiel tust du nix). Waehrend das Modelbasierende Dir schon für standardanwendungsfall optimiert.

Sortieren / filtern passt aber genau so ins Moodell-basierende.

Eigentlich iss ja QStandardItemModel schon nen Model ... das doofe nur es mappt es wieder zurueck auf ein Itembasierendes Model ^^

zum Testen:
Mach mal nen eigenes Model, leite von QAbstractItemModel ab.
Ueberschreibe die notwendigen virtuellen methoden.
und wichtig, generier "daten" nur bei Abfrage ueber die data() methode des Models. Vermeide da das new, sondern erzeug nur die strings local aufn Stack.
und wetten, das ding wird 1000 mal performanter sein.
Und ne gute Übung fuer Dich in das Thema reinzukommen.

Ciao ...

[dermm13]

Vielen Dank!
Ich habe ein eigenes Model (abgeleitet von QAbstractTableModel) verwendet um eine Tabelle zu füllen. Dies ist viel viel viel schneller als über QSortFilterProxyModel/QStandardItemModel…
Das war wohl meine eigene Faulheit. Ich versuche erst mal das Vorhandene zu verwenden.

[RHBaum]

Das war wohl meine eigene Faulheit. Ich versuche erst mal das Vorhandene zu verwenden.

Was auch gar ned so verkehrt ist !
WIr leben bzw. verdienen unser Geld in einer Welt, die von "Faulheit" getrieben wird Programme schreibt man ja eigentlich, um immer wiederkehrende Dinge automatisieren zu können, also unter anderem

Ne Programmierer-Regel sagt auch:
Erst mal mit minimalen Aufwand eine Klasse / Funktion zu implementieren. Danach schauen, ob sie den Anforderungen genuegt. Danach kann man immer noch optimieren
Zumindest wenn man fuer konkrete anwendungsfaelle programmiert, iss das ne gute Regel
Und der Positive Nebeneffekt: man lernt sein Zeugs gescheit zu kapseln nebenher

Ciao ...