QTreeView performance slowdown...

[jpujolf]

Hi all,

I'm having a very strange slowdown in performance of QTreeViews.

I use them extensively in EVERY grid I've to show in my application. I've created an object, called MGridView that contains 2 QTreeViews ( to achieve columns locking ), 4 QHeaderViews ( footer counters and header bands x 2 QTreeViews ) and an horizontal QScrollbar.

Everything goes OK & fast. The models associated to those objects are very optimized and I can manage 15000 rows, 30 columns without problems ( with selection boxes, decoration, alignment, fonts ... )

In a form I have, that shows a lot of grids ( 27 "MGridViews" exactly ), all of them are individual pages of a hierarchy of QTabViews, so there are at least 200 widgets inside the "form". I've not counted them exactly.

The performance slows down too much, i.e : pressing key down takes about 0.1 secs to change row position ( usually takes 1/10 of that time )

None of the "grids" has a lot of data ( the one I'm testing has only 106 rows ).

I've been profiling, catching RowChanged event and my code works great ( it's almost inexpensive ). So I suspect it's something in QT code that takes a lot of time.

Any clues ? There is any known limitation in the number of widgets that QT can manage in a form ?

Thanks...

[wysota]

Using too many widgets can indeed cause some slowdowns, but in layouting and not in event handling, so that's probably not it. Do cells in your views have fixed widths/heights? Do you use "uniform item height"?

[jpujolf]

Hi wysota,

I'm using setUniformRowHeights ( true ) FIXED in both QTreeViews of my object. It's very strange...

Width is not fixed, so user can change / parametrize columns widths. But I suspect that's not the problem, because my model's "data" method is very optimized and I've tried to comment code, returning only data without decorations, widths, images, colors... and there is no difference in speed.

Only not setting a model ( showing an empty grid ) speeds up. But is an obvious test I've made too.

If I set the model for every grid ( 27 models ) it slows down a lot. It depends on the number of "grids" with a populated model. But the strange thing is that only 2 grids are visible at the same time ( they are pages of a QTableView ) so there is no need for calls to my data method.

And also changing between tab pages takes about 1 second ?!?

Strange, very strange...

One last thing. I've forgot tell you I'm using Qt 4.4.0 on a linux machine ( Ubuntu 8.04, gcc 4.2.4 ) and a WinXp / Qt4.4.0-MingW bundle. On windows runs at least 1/2 speed than in Linux, I don't know why

[jpujolf]

There are 2 screenshots of the "BIG SCREEN"...

[wysota]

Do you have any resizeToContents resize modes set up on the headers? Do you use proxy models? Have you tried profiling your application? What takes the most time?

[jpujolf]

Do you have any resizeToContents resize modes set up on the headers?

No. I left the default values ( QHeaderView::Interactive ) so users can move the header to resize columns.

Do you use proxy models?

No. I've tried, but I've had more problems than results. In fact, both QTreeViews share the same model...

Have you tried profiling your application?

Well, I'm trying with oprofiler, but it's toooooo big to profile. I've done a very simple profiling ( with a global class that implements a "call & time spent" counter ) and it's not my code the one that works slow. The spent time inside my code is about to 0.07 seconds while wasting 12 secs. to scroll 106 rows down one by one.

And changing from tab to tab is about 0.5 / 1 second... Too slow !! And not related to models, I suspect...

What takes the most time?

QT painting ? Arghhhh I'm going crazy....

Thanks anyway, I will test if Qt 4.5 has any painting improvement. In fact I suspect about QTabWidget ( too many childs... )

I have a crazy idea. I could make a test : put 27 grids alone in a big form & try to move. Perhaps it works an I can isolate the problem...

I'll try and tell you the results. Many thanks...

POST-EDIT :

I've made the test ( a funny screen, with 27 grids full of data ) and works great !! So, it seems that the problem resides in the complexity of Tab's hierarchy.

I've attached the .ui file, to show you the complexity of the problem ( can be minimized, but not too much ). Is there any flag / option to speed up things ? Please, tell me that exists the "don't-fuck-the-programmer" flag, pleaseeeeee....

I'm overloading QTableView/Widget & QTreeView/Widget to put my MGridView, so you must take ALL grids as QTreeViews.

[wysota]

You have to profile not your code but Qt, thus using your own classes for it won't work. Use callgrind, gprof or a similar tool.

[jpujolf]

You have to profile not your code but Qt, thus using your own classes for it won't work. Use callgrind, gprof or a similar tool.

I'm working on this. I'll tell you the result, if I can finally find the origin of the problem.

[wysota]

I'm sure the reason will become obvious once you run the profiler.

[calmspeaker]

I'm sure the reason will become obvious once you run the profiler.

Hi, wysota
now I see profiler again.Is there a opensource or free profiler in the platform windows?

[wysota]

There are many profiling tools. I'm sure gprof is available for Windows as well. Maybe even Visual Studio has a built-in profiler.