QStandardItem::setData takes too much time

marcus.fr

Hi

I use QTreeView with QStandardItemModel. I update tool tip (QStandardItem::setToolTip) every second from a secondary thread using queued connections. Only one item is updated per second. This call hangs the QUI for about 150-200ms. When I collapse the items that have their tooltips updated on each second there is no more delay. The same happens when I simply want to update User Role data of an item on each second. There is no GUI update in these calls, why there is such a delay? The QStandardItemModel is related to a single view object - QTreeView.

andre

[quote author="Marcus Frenkel" date="1332514997"]I use QTreeView with QStandardItemModel. I update tool tip (QStandardItem::setToolTip) every second from a secondary thread using queued connections.[/quote]
This is where you already go wrong. You cannot do that. You cannot modify any GUI element from any thread other than the GUI thread, which is usually your main thread.

marcus.fr

[quote author="Andre" date="1332517145"]This is where you already go wrong. You cannot do that. You cannot modify any GUI element from any thread other than the GUI thread, which is usually your main thread.
[/quote]

I wasn't clear I'm using queued connections. In secondary thread I call:
@QMetaObject::invokeMethod(obj,"SlotInGuiThread",Qt::QueuedConnection)@

What I mentioned about the secondary thread is not the cause of issue. This is the problem is simple words:

GUI Thread, working on QStandardItemModel attached on QTreeView:

Appended 100 rows/7 columns full of displayed text and internal data. Took 20ms avg
Changed User Data value of a single QStandardItem. Took 200ms avg
Changed Display Data value of a single QStandardItem. Took 250ms avg
Changed Tooltip Data value of a single QStandardItem. Took 230ms avg

It is faster to just delete and insert a whole new table than to change a single item.

marcus.fr

I ended up with a workaround: take the whole row, change the item, insert the row again. Works pretty fast.

DerManu

Does really the setData call take so long or is it the delay between the signal emission and slot execution due to the queued connection? You could test that with some timing debug output:
@qDebug() << "start" << QDateTime::currentDateTime().toMSecsSinceEpoch();
item->setData(...)
qDebug() << "stop" << QDateTime::currentDateTime().toMSecsSinceEpoch();@

marcus.fr

[quote author="DerManu" date="1332634658"]Does really the setData call take so long or is it the delay between the signal emission and slot execution due to the queued connection? You could test that with some timing debug output:
@qDebug() << "start" << QDateTime::currentDateTime().toMSecsSinceEpoch();
item->setData(...)
qDebug() << "stop" << QDateTime::currentDateTime().toMSecsSinceEpoch();@[/quote]

Yes, to test it I called the setData function directly in the GUI thread, without using threads at all. I use QTime:start QTime:elapsed() to measure the time span.