QModel set data to item very slow

[fatecasino]

I have implemented my own (very simple though) QStandardItemModel-qtableview.


#ifndef PARAMETERMODEL_H
#define PARAMETERMODEL_H
#include <QtGui>
#include <QtSql/QSqlTableModel>
#include <QtSql/QSqlRelationalDelegate>
#include <QtSql/QSqlQuery>
#include <QMessageBox>
#include <QComboBox>
#include <QWidget>


#include <comboboxDelegates.h>
#include <spinboxdelegates.h>

class ParameterModel : public QWidget
{
Q_OBJECT

public:
ParameterModel( QWidget *parent = 0);

QStandardItemModel* model;
QTableView* tableView;



public slots:
void addNewRow();
void addNewRow2();

void deleteRow(int);
private:
QVBoxLayout* vboxlayout;

ActionComboBoxDelegate *actionComboBoxDelegate;
TypeComboBoxDelegate *typeComboBoxDelegate;
StatusComboBoxDelegate *statusComboBoxDelegate;

VrotSpinBoxDelegate *vrotSpinBoxDelegate;
SigmaSpinBoxDelegate *sigmaSpinBoxDelegate;
GammaSpinBoxDelegate *gammaSpinBoxDelegate;
XiSpinBoxDelegate *xiSpinBoxDelegate;
SemitSpinBoxDelegate *semitSpinBoxDelegate;
DlradSpinBoxDelegate *dlradSpinBoxDelegate;
LlabSpinBoxDelegate *llabSpinBoxDelegate;
AWSpinBoxDelegate *aWSpinBoxDelegate;
EiSpinBoxDelegate *eiSpinBoxDelegate;


};
#endif // PARAMETERMODEL_H
I usually need 3-5 of these, which I append them to a QVector


QVector<ParameterModel*>* modelVector;


My problem is that when I am trying to set the data to the items, it gets slow


QElapsedTimer t;
t.start();
if ( column_index < 4 )
modelVector->at(model_index)->model->item(row_index,column_index)->setData(line);
qDebug()<<t.elapsed();
t.start();
if ( column_index > 4 )
modelVector->at(model_index)->model->item(row_index,column_index)->setData(line.toDouble());
qDebug()<<t.elapsed();

The timers here give values 500-600. The strange thing is that the output is usually like this (I run it multiple times)
0
593
....
577
0
....
562
0
etc,etc.
What can I do to make it faster?

[d_stranz]

I have implemented my own (very simple though) QStandardItemModel-qtableview.

Well, no you haven't. You've implemented a QWidget, which for some strange reason you call ParameterModel, and which contains public member variables of types pointer to QStandardItemModel and pointer to QTableView, along with a bunch of pointers to child widgets.

Then, floating out in interplanetary space, you have a pointer to a QVector of pointers to ParameterModel instances, and in another piece of interplanetary space, you have some code that uses a pointer from that vector to access a model that you set some data into.

You don't bother to show us how you create that vector, how you create the instances of the ParameterModel widgets inside it or the children of those widgets, how you arrive at the model_index, row_index, and column_index values for the item you are trying to change. Just code floating in space, drifting along, trying to stay out of the way of planets, asteroids, and comets as it spirals into the Sun...

How are we supposed to be able to understand what might be wrong, much less help?

[fatecasino]

:D
well...ok you are totally right, my intention was to focus on the setData function. Otherwise I had to present perhaps too many lines of code that probably noone would get into the trouble to read.
Anyway, the fact is that I am implementing a big-idea-math tool, which I had never realized its actual complexity (perhaps not even now). It is when you are a part of a team and every now and then it is revealed to you another very-very important part of the algorithm that had never been mentioned before :)

When I started I didn't know the existence of QT, that's why all these come from outer space and seem loosely designed. Miraculously, after really hard time in front of the computer it works so far fine.


You've implemented a QWidget, which for some strange reason you call ParameterModel, and which contains public member variables of types pointer to QStandardItemModel and pointer to QTableView, along with a bunch of pointers to child widgets.
Regardless the fact that I wanted a custom QStandardItemModel and I implemented a QWidget (I really can't remember why I did this, I think I needed some functions of QWidget that were not available in QStandardItemModel, has this any performance effect?) the bunch of pointers are my delegates. All the examples I found were declaring the delegates in this way.


Then, floating out in interplanetary space, you have a pointer to a QVector of pointers to ParameterModel instances, and in another piece of interplanetary space, you have some code that uses a pointer from that vector to access a model that you set some data into.

Come on, this can be easily guessed :) , I have a Vector which stores ParameterModels dynamically. While on run the user can create or destroy these models.


You don't bother to show us how you create that vector, how you create the instances of the ParameterModel widgets inside it or the children of those widgets,


modelVector = new QVector<ParameterModel*>(0);
.............
ParameterModel* m = new ParameterModel;
modelVector->append(m);
...............


how you arrive at the model_index, row_index, and column_index values for the item you are trying to change.

this is a detail, while the program runs, these indexes work well,trust me!


Just code floating in space, drifting along, trying to stay out of the way of planets, asteroids, and comets as it spirals into the Sun...
well, I have to tell you that the last half an hour I 've abandoned the keyboard and I have caught my guitar to write a song with these lyrics :cool:

Now...can I make this thing set the model data a bit faster?

[wysota]

How have you identified this is setData which is slow and not the view update which comes after it?

[d_stranz]

How have you identified this is setData which is slow and not the view update which comes after it?

Exactly why more detail is needed. If the QElapsedTimer instrumentation is in the code as originally posted, then I don't think the code re-enters the event loop to update the GUI until after whatever is happening in the code that calls setData() finishes.

QStandardItemModel does override setData(), but would it internally force events to be processed?