[Interest] need advise on QStandardItemModel vs. QAbstractTableModel

[Andreas Pakulat]

Hi,

On Wed, Jan 13, 2016 at 11:07 PM, Frank Rueter | OHUfx <frank at ohufx.com>
wrote:

> Thanks Bo,
>
> when you say "it's bad in so many ways", are you referring to performance?
>
> I just realised that my last conversation with Jason had dropped the CC to
> the list, so here it is again :
>
> so a few lines into the new code and I believe I'm starting to realise
> that QAbstractTableModel is the wrong choice for me, let's see if I get
> this right:
>
> I need each cell to:
>
>    - store a reference to a custom object in the host application
>    - get it's background and foreground colour from the host
>    application's object
>    - determine the right delegate output based on the data type/ external
>    object class
>    - drive the external object's value upon datatChanged
>    - etc.
>
> When I got as far as implementing the background role in my
> QAbstractTableModel's data method, the resulting view took about 4 seconds
> to resize, while scrolling left me with the ol' spinning beach ball (OSX).
> The same code utilising QStandarItemModel reacts instantaneously without
> trouble, even with way more data.
>
> I suppose this is because I am storing those object references in each
> QStandarItem as I construct the data when using QStandarItemModel. So later
> on, those values are readily available within my data model.
> When putting those references into QAbstractTableModel.data(), they are
> constantly called upon as the view changes, causing the massive slow down.
>
> In order to keep the view fast, I need to refactor my code and somehow
> store the custom data only once, so things like background colour etc. are
> determined within my model's data when needed, rather than having to call
> the host application constantly to retrieve the same info.
> Which essentially turns the table model into an item model, and I might as
> well use the QStandardItemModel or at least QAbstractItemModel to begin
> with.
>
> Does that sound about right?
>
>
> Bo, reading your reply makes me feel like I should keep playing with
> QAbstractTableModel (or QAbstractItemModel) and write all the behaviour I
> need from QStandardItemModel myself?
> I feel like the item based approach is handier as I can subclass a
> QStandardItem and give it a reference to the external object it represents,
> then have the data read/write from/to that.
> I don't think I get that with a table model unless I re-invent the wheel.
>
> Any thoughts on the above?
>

First of all: Take this with a grain of salt, I haven't written a custom
item model since a few years now and have also not kept up to speed with
changes in the QStandardItemModel.

One thing to keep in mind with the item model is that it requires to create
an object for each and every item. That onehas a another object as
d-pointer which then has a bunch of member variables that also need memory.
So depending on what you use from it and how many items you have, your
memory footprint increases quite a bit without providing anything that you
actually use.

The idea with the custom model is that you only have the data in memory
that is really 'stored' and you calculate everything for the view on the
fly (like colors etc.) from this bare minimum of data. So the memory
footprint can get smaller with this - especially with a huge number of
items - but of course it means access to the data must be fast. Or you need
to consider to cache some (but not all) of the data 'up front' to make it
seem fast (I think this happens - behind the scenes - with sql table models
based on queries).

You could still benefit from imlementing a custom model event if it
replicates some of the item model's logics. If the struct you use for
storing the attributes to be returned from data() is considerably smaller
than the qstandarditem class your overall memory footprint might decrease
while the performance is kept at par with the standard item model.

Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160114/c3a55fca/attachment.html>