[Interest] QTableWidget performance

[Bo Thorsen]

Hi Paul

Den 14-03-2012 23:54, Paul England skrev:
> I've got an old legacy application that I started in Qt3 and have since
> ported to Qt4. It uses a subclassed QTableWidget. I'm using about 8
> columns. Data is added at various rates, but I would say by the end of
> the day, it could have several thousand rows. To boot, I'm actually
> kicking off multiple copies of this class within one process now. As
> such, I'm starting to see poor performance as the day gets later. If I
> tail the log, the log tells me it's gotten the data and updated it, but
> the screen doesn't paint the new items until later.

The proper answer to this is that you need to run this through a 
profiler. You know, premature optimization...

If your code runs on Linux, you should take a look at KCacheGrinder.

> Generally two things happen after getting a new message
> 1: Look through the last 200 - 300 records -- if it's an update, update
> that cell.
> 1B: The caveat here is there maybe something that should be updated, but
> I'm assuming it's old at that point and don't care if it's repainted.
> 2: If it's new, insertRow( 0 ) and fill this row w/ the data.
>
> Each time I insert a row, I store the identifier w/ it's "index" in a
> deque. The deque generally only holds 200-300 records, so the look up is
> quite fast. I am assuming that searching through std::deque<my_map_t>
> (where my_map_t has a QString and int member only) is faster than going
> through each row and examining the QTableWidgetItem of a specific cell.
>
> My main question is, insertRow() in a QTableWidget with 10 rows, as fast
> as insertRow on a QTableWidget with 10,000 rows? I've done quite a bit
> of housecleaning to make it quicker, and I've seen good results, but not
> quite there yet, as I can visually see. I have loaded up a table in a
> test mode, with some 20,000 rows of data, and can simulate adding a
> couple of rows a time. I do not see the delay, so my guess is that
> insertRow() is not that big of a deal. The problem is that means I have
> no clue where the performance issue is. :(
>
> The obvious questions is of course, should I use a QTableView instead?

Impossible to answer, when you don't know what the problem is.

I *really* don't like the *Widget versions, and will always tell my 
customers to go with a proper model (not a QStandardItemModel based), 
but that's for other reasons.

> My main resistance to this is that while the data is somewhat simple, I
> already have a pretty complex system to filter what should be displayed
> and what shouldn't, what colors should be displayed for visible items,
> what font to use, and whether a sound should be played or not. This is
> all configured by the user in the GUI.

Aha, that might very well be the reason. You should try and remove the 
filter code completely and see if this solves the problem. Those filters 
can be very expensive to calculate.

Bo Thorsen,
Fionia Software.

-- 

Expert Qt and C++ developer for hire
Contact me if you need expert Qt help
http://www.fioniasoftware.dk