Qt-interest Archive, April 2007
Re: QListView Performance Analysisy
Message 1 in thread
Mark,
I can't run your code until I get home, but this does sound very bad. 1600 or even 16,000 items is not a huge amount of data. I suggest trying the same code with QTableView which I am sure will not call data() on cells outside the current viewport. This is definatly a case for qt-bugs at trolltech. The troll engineers post to this list on thier own time. Writing support at trolltech.com or qt-bugs at trollech.com will get you a formal response.
--Justin
-----Original Message-----
From: Mark Beckwith <mark@xxxxxxxxxx>
Subj: Re: QListView Performance Analysis
Date: Fri Apr 20, 2007 9:26 pm
Size: 806 bytes
To: Scott Aron Bloom <scott@xxxxxxxxxxxx>
cc: qt-interest@xxxxxxxxxxxxx
Scott,
Thanks for the response.
On Fri, Apr 20, 2007 at 03:29:50PM -0700, Scott Aron Bloom wrote:
>
> But the layout itself is a O(N)
This is really, really unfortunate. I've tried the other things you
suggested but it doesn't get around this problem. If this is true, then
Qt 4 is just not ready for primetime.
It would be nice for a Troll to chime in on this one. Also, the complexity
of O(n) should be posted in the documentation so poor guys like me don't
spend the time to port to model/view.
Mark
On Fri, Apr 20, 2007 at 03:29:50PM -0700, Scott Aron Bloom wrote:
--
[ signature omitted ]
Message 2 in thread
On Fri, Apr 20, 2007 at 11:12:00PM -0400, Justin Noel wrote:
> Mark,
>
> I suggest trying the same code with QTableView...
>
Justin,
Thanks for the advice.
I updated my test program to optionally use a QTableView instead. It's
running now with almost 50,000 entries and CPU usage is at a constant 3%.
I also submitted a bug report to Trolltech. I can't believe they are not
aware of this though. Maybe I am the first one to acutally use the MVC
architecture :-).
You can still download the test program:
wget http://www.intrig.com/lvtest.tgz
run "lvtest table" to get the table version.
Mark
--
[ signature omitted ]
Message 3 in thread
I think they are going to have to "add an optimization" for constant row
size. What I see happening, is for each row of the list view they are
getting the icon, the text to compute the height and the check box if
its there, compute the height per row, and then figure out what is
visible in the scroll view, and do it again for the area to be
painted...
And they redo it from row 0 every time you modify the list.
Scott
> -----Original Message-----
> From: Mark Beckwith [mailto:mark@xxxxxxxxxx]
> Sent: Saturday, April 21, 2007 10:52 AM
> To: Justin Noel
> Cc: qt-interest@xxxxxxxxxxxxx
> Subject: Re: QListView Performance Analysisy
>
> On Fri, Apr 20, 2007 at 11:12:00PM -0400, Justin Noel wrote:
> > Mark,
> >
> > I suggest trying the same code with QTableView...
> >
> Justin,
>
> Thanks for the advice.
>
> I updated my test program to optionally use a QTableView instead.
It's
> running now with almost 50,000 entries and CPU usage is at a constant
3%.
> I also submitted a bug report to Trolltech. I can't believe they are
not
> aware of this though. Maybe I am the first one to acutally use the
MVC
> architecture :-).
>
> You can still download the test program:
>
> wget http://www.intrig.com/lvtest.tgz
>
> run "lvtest table" to get the table version.
>
> Mark
>
>
> --
> Mark Beckwith (mark@xxxxxxxxxx)
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 4 in thread
Hi all,
we at MyARM had the same problem with the QTreeView widget and last week
we find a SIMPLE soluation! We do a lazy loading of (sub-)trees from a
SQL-Database with upto 200-500k items or even more. After debugging the
QTreeView and understanding some internals we figured out that the only
problem causing this performance bottleneck is the computation of the
row height of each single item. As Scott mentioned below each time the
view position is changed it iterates through the items from 0 to the
currently drawn items to calculate the row height of EACH SINGLE ROW
(worst case til the end of the tree). Now we saw in the documentation
the property uniformRowHeights which is documented as follows:
uniformRowHeights : bool
This property holds whether all items in the treeview have the same height.
This property should only be set to true if it is guaranteed that all
items in the view has the same height. This enables the view to do some
optimizations.
Access functions:
* bool uniformRowHeights () const
* void setUniformRowHeights ( bool uniform )
Setting this property to true fixes all our performance problems with
the QTreeView! We can navigate through the complete tree within 100-200
ms! But don't use the keyboard navigation, if you press '+' or '-' it
will also iterate through all items and in our case it will trigger
200-500k SQL selects.... ;-(
My question is why is this property not set to true by default? In most
cases a normal TreeView items have the same height using the same font.
If someone really wants to have different row-sizes he/she can set this
property to false! Just my opinion.
Also the documentation is a little bit laxly: "This enables the view to
do some optimizations." Not some, but much-needed for large number of
items in the view!!!
Regards,
Stefan
--
[ signature omitted ]
Message 5 in thread
And, for those of us using the QListView class, the magic property is:
uniformItemSizes : bool
Set this to true and things really settle down. Looks like complexity is
back to O(1) as we expected. Nice Stefan.
Mark
On Tue, Apr 24, 2007 at 10:25:52PM +0200, Stefan Ruppert wrote:
> Hi all,
>
> we at MyARM had the same problem with the QTreeView widget and last week
> we find a SIMPLE soluation! We do a lazy loading of (sub-)trees from a
> SQL-Database with upto 200-500k items or even more. After debugging the
> QTreeView and understanding some internals we figured out that the only
> problem causing this performance bottleneck is the computation of the
> row height of each single item. As Scott mentioned below each time the
> view position is changed it iterates through the items from 0 to the
> currently drawn items to calculate the row height of EACH SINGLE ROW
> (worst case til the end of the tree). Now we saw in the documentation
> the property uniformRowHeights which is documented as follows:
>
> uniformRowHeights : bool
>
> This property holds whether all items in the treeview have the same height.
>
> This property should only be set to true if it is guaranteed that all
> items in the view has the same height. This enables the view to do some
> optimizations.
>
> Access functions:
>
> * bool uniformRowHeights () const
> * void setUniformRowHeights ( bool uniform )
>
> Setting this property to true fixes all our performance problems with
> the QTreeView! We can navigate through the complete tree within 100-200
> ms! But don't use the keyboard navigation, if you press '+' or '-' it
> will also iterate through all items and in our case it will trigger
> 200-500k SQL selects.... ;-(
>
> My question is why is this property not set to true by default? In most
> cases a normal TreeView items have the same height using the same font.
> If someone really wants to have different row-sizes he/she can set this
> property to false! Just my opinion.
>
> Also the documentation is a little bit laxly: "This enables the view to
> do some optimizations." Not some, but much-needed for large number of
> items in the view!!!
>
> Regards,
> Stefan
>
> --
> Stefan Ruppert <stefan.ruppert@xxxxxxxx> MyARM GbR
> CEO/Head of Development Neue Str. 4
> Phone: +49 6192/9772818 63571 Gelnhausen-Roth
> Web: http://www.myarm.de Germany
> MyARM: Application Response Measurement tools for C/C++ and Java
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
--
[ signature omitted ]
Message 6 in thread
The worst part... On my last project, I used both properties, and
completely forgot about them... For the tree view I needed it for
performance, (the fix was a suggestion from TT support) the other I
needed it to work around a bug in 4.1
Scott
> -----Original Message-----
> From: Mark Beckwith [mailto:mark@xxxxxxxxxx]
> Sent: Wednesday, April 25, 2007 7:17 AM
> To: Stefan Ruppert
> Cc: qt-interest@xxxxxxxxxxxxx; Scott Aron Bloom; Justin Noel
> Subject: Re: QTreeView performance hint! (was Re: QListView
Performance
> Analysisy)
>
> And, for those of us using the QListView class, the magic property is:
>
> uniformItemSizes : bool
>
> Set this to true and things really settle down. Looks like complexity
is
> back to O(1) as we expected. Nice Stefan.
>
> Mark
>
> On Tue, Apr 24, 2007 at 10:25:52PM +0200, Stefan Ruppert wrote:
> > Hi all,
> >
> > we at MyARM had the same problem with the QTreeView widget and last
week
> > we find a SIMPLE soluation! We do a lazy loading of (sub-)trees from
a
> > SQL-Database with upto 200-500k items or even more. After debugging
the
> > QTreeView and understanding some internals we figured out that the
only
> > problem causing this performance bottleneck is the computation of
the
> > row height of each single item. As Scott mentioned below each time
the
> > view position is changed it iterates through the items from 0 to the
> > currently drawn items to calculate the row height of EACH SINGLE ROW
> > (worst case til the end of the tree). Now we saw in the
documentation
> > the property uniformRowHeights which is documented as follows:
> >
> > uniformRowHeights : bool
> >
> > This property holds whether all items in the treeview have the same
> height.
> >
> > This property should only be set to true if it is guaranteed that
all
> > items in the view has the same height. This enables the view to do
some
> > optimizations.
> >
> > Access functions:
> >
> > * bool uniformRowHeights () const
> > * void setUniformRowHeights ( bool uniform )
> >
> > Setting this property to true fixes all our performance problems
with
> > the QTreeView! We can navigate through the complete tree within
100-200
> > ms! But don't use the keyboard navigation, if you press '+' or '-'
it
> > will also iterate through all items and in our case it will trigger
> > 200-500k SQL selects.... ;-(
> >
> > My question is why is this property not set to true by default? In
most
> > cases a normal TreeView items have the same height using the same
font.
> > If someone really wants to have different row-sizes he/she can set
this
> > property to false! Just my opinion.
> >
> > Also the documentation is a little bit laxly: "This enables the view
to
> > do some optimizations." Not some, but much-needed for large number
of
> > items in the view!!!
> >
> > Regards,
> > Stefan
> >
> > --
> > Stefan Ruppert <stefan.ruppert@xxxxxxxx> MyARM GbR
> > CEO/Head of Development Neue Str. 4
> > Phone: +49 6192/9772818 63571
Gelnhausen-Roth
> > Web: http://www.myarm.de Germany
> > MyARM: Application Response Measurement tools for C/C++ and Java
> >
> > --
> > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx
with
> "unsubscribe" in the subject or the body.
> > List archive and information:
http://lists.trolltech.com/qt-interest/
> >
>
> --
> Mark Beckwith (mark@xxxxxxxxxx)
--
[ signature omitted ]
Message 7 in thread
Mark,
As a side note it also seems that QTableView is still a bit overzelous in repainting the whole viewport for every insert. An optimization needs to be added to not update on inserts that do affect the current viewport.
--Justin
-----Original Message-----
From: Mark Beckwith <mark@xxxxxxxxxx>
Subj: Re: QListView Performance Analysisy
Date: Sat Apr 21, 2007 1:51 pm
Size: 642 bytes
To: Justin Noel <justin@xxxxxxx>
cc: qt-interest@xxxxxxxxxxxxx
On Fri, Apr 20, 2007 at 11:12:00PM -0400, Justin Noel wrote:
> Mark,
>
> I suggest trying the same code with QTableView...
>
Justin,
Thanks for the advice.
I updated my test program to optionally use a QTableView instead. It's
running now with almost 50,000 entries and CPU usage is at a constant 3%.
I also submitted a bug report to Trolltech. I can't believe they are not
aware of this though. Maybe I am the first one to acutally use the MVC
architecture :-).
You can still download the test program:
wget http://www.intrig.com/lvtest.tgz
run "lvtest table" to get the table version.
Mark
--
[ signature omitted ]
