[Qt-interest] QTreeView and custom QAbstractItemModel performance problem

[Felix Brack]

On 07/09/2010 01:58 PM, Andre Somers wrote:
> On 9-7-2010 13:50, Felix Brack wrote:
>> On 09.07.2010 12:06, Andre Somers wrote:
>>> On 9-7-2010 11:57, Felix Brack wrote:
>>>> an
>>>> Well, I had no hasChildren() until now... My new hasChildren() looks
>>>> like this:
>>>>
>>>> bool CMultiColumnListModel::hasChildren(const QModelIndex& Parent)
>>>> const
>>>> {
>>>> return (QModelIndex()==Parent);
>>>> }
>>>>
>>>> Adding hasChildren() however does not change things with respect to
>>>> performance and CPU load.
>>>>
>>> If I understood you correctly, your model represents a table, right?
>>> That means: no children to any of the items.
>>>
>>> If so, why not just implement the above as:
>>>
>>> bool CMultiColumnListModel::hasChildren(const QModelIndex& Parent) const
>>> {
>>> Q_UNUSED(Parent)
>>> return false;
>>> }
>>>
>>>
>>> André
>>>
>> In fact it is a table, yes. There is one root item. All rows have the
>> root item as parent. Every row consist of the same number of columns.
>> The existence of a root item leads to my code of hasChildren().
>>
>> Felix
> Hmmm... I see.
>
> Would it be possible to ditch your root item and make it a real table?
> Or do you have other things in your view as well?
> Wouldn't it be faster to test Parent.isValid() instead of comparing with
> a newly constructed QModelIndex every time?
>
> André
>
You mean move from TreeView to TableView, right? I can (and probably 
will) do that but it's really the last resort. Furthermore when looking 
at what the TableView can do I will have to switch off about everything. 
For what I want the TableView is like taking sledgehammer to crack a 
nut. I just want a protocol, say 200 lines, first column shows an icon 
and when it's full the oldest data gets discarded.

As already stated: I don't think (I might be wrong of course) it is 
performance problem of any function in the data model (including 
hasChildren). The problem is the view requesting the same information 
again and again from the data model. I have been able to prove this with 
a very stupid data() function in an earlier post.
Of course this could be wrong; that would be the case if I missed to 
implement a function in my data model that stops the view from queering 
the same values again and again; that function however is not yet known 
to me.

Felix