Qt World Summit: Register Today!

QStandardItemModel vs QAbstractItemModel

  • Hello,

    Now I'm implementing QTreeView but not sure which model I should choose between QStandardItemModel and QAbstractItemModel, in terms of cost(eg.performance)
    In my understanding, QAbstractItemModel is flexible enough enabling everything, while QStandardItemModel is convenient saving implementation cost but I guess this costs much compared to QAbstractItemModel.

    The view is going to have parent-children hierarchy.
    Does anybody know the benchmark of the two models?

    Thanks in advance for your update.

  • Hi @ShinSat,

    This is just my own personal approach, but I'd say: if QStandardItemModel offers anything useful over QAbstractItemModel for your use case (sounds like it definitely would given that you want to use QTreeView), then I'd start with QStandardItemModel.

    In my experience, performance issues tend to be focused in specific small areas (eg in QStandardItemModel::data(), but you're unlikely to know where until you can do some real testing / benchmarking, and using QStandardItemModel should allow you to get there more quickly. So, let QStandardItemModel take of a lot of the basics, so you to get to the real project challenges quicker. You can (and should) then override anything in QStandardItemModel that causes performance issues for your use case later.

    Another way to look at is: Just because QStandardItemModel might impose some performance impact, in most cases the impact is much less than your own code would impose, unless you spend a lot of time optimising (just think how much effort has gone into Qt's own implementation). Yes, Qt's implementation might be more generic, but again, leaning on Qt's generic implementations can allow you to get straight to the core challenging cases for you to then optimise heavily for your own scenario(s), without wasting a lot of time reinventing stuff that might already be more than fast enough for you.

    Just my approach anyway.

    Good luck :)

Log in to reply