Warum ist Qt sooo langsam?? (nur bei mir??)

[JoseMan]

Hallo,

ich suche schon eine ganze Weile, in meinem Code, um die "Bremsen" hrauszufinden....!
Ich habe bis jetzt alles aus einer Schleife rausgenommen was geht, es ist also eine ganz simple For-Schleife

Code: Alles auswählen

for(unsigned int zaehler(0); zaehler<(breite*hoehe); ++zaehler)
{

}
QMessageBox::information(NULL,QString("TEST"),"Ende");

Wie mann sich denken kann, kommt die MessageBox nach vlt 1-2 Sekunden.

Jedoch wenn ich nun folgendes schreibe:

Code: Alles auswählen

for(unsigned int zaehler(0); zaehler<(breite*hoehe); ++zaehler)
{
  fortschrittDialog->getProgressBar()->setValue(zaehler);
}
QMessageBox::information(NULL,QString("TEST"),"Ende");

Ist die Schleife nach ca. 1-2 MINUTEN(!!!) beendet, also der Dialog poppt dann auf.

Kann das sein????!!!???
Kann man was dagegen tun?
Arbeite unter Windows 7; VS2005; Qt 4.5.1.

Gruß JoseMan

[RHBaum]

Kann das sein????!!!???

wieviel ist denn breite mal hoehe ?
wenn ich zig millionen mal ne windows message zum updaten eines Progressbar controls abschicke, iss bei mir selbst unter der winapi direkt der rechner sicher ne minute beschaeftigt ^^

Kann man was dagegen tun?

in sinnvollen abstaenden updaten ?
jedes Promille an Fortschritt melden macht ned unbedingt sinn oder ?


for(unsigned int zaehler(0); zaehler<(breite*hoehe); ++zaehler)
{
if ((zaehler%1000) == 0) fortschrittDialog->getProgressBar()->setValue(zaehler);
}
wirds nu schneller ?

Und Fazit der Geschichte: GUI Operationen sind schweineteuer ! (auch bei der QT)

Ciao ...

[franzf]

Ein ordentlicher Compiler wird dir im ersten Beispiel die Schleife wegoptimieren. Da das anscheinend trotzdem 1-2 Sekunden dauert, wird die Schleife scheinbar doch abgearbeitet (obwohl tatsächlich nichts passiert, und der Compiler das auch sieht!).

Dass es dann 1-2 Sekunden dauert, sagt mir dass breite und hoehe ziemlich groß sein müssen. Kann es evtl. auch sein, dass du da in einen kleinen Überlauf reinkommst?

Als kleine Optimiierung (wenn der Compiler schon zu doof dafür ist ) kannst du breite*hoehe vor Eintritt in die Schleife ausrechnen und in eine unsigned int-Variable speichern. Dann sparst du dir pro Durchlauf eine Berechnung.

Und zu guter letzt: Wenn breite*hoehe tatsächlich so groß ist wie ich mir das denke, macht es absolut keinen Sinn, bei jedem Durchlauf die Progressbar zu ändern. Jedes "setValue()" resultiert in einem update() der Progressbar. Bei max-min > 200 macht mMn. eine feinere Unterteilung der Progressbar nicht so viel Sinn - wenn die Progressbar tatsächlich für einen Fortschritt benutzt wird und nich als exakter Indikator für einen bestimmten Wert (siehe z.B. aktuelle Entwicklung bei "krita". Unnötiger Rechenaufwand
Also in der Schleife die Progressbar nur aktualisieren wenn es notwendig ist. Z.B. Berechnung mit Modulo, oder eine zweite Zählvariable mitlaufen lassen und wenn die auf z.B. 100 kommt den Progress erhöhen und die Zählvariable wieder auf 0 setzen, oder sonstwas (sei kreativ )

Ich mir ziemlich sicher, dass deine Performanceprobleme nicht bei Qt zu suchen sind.

[JoseMan]

Jo, danke für die Tipps.
Leuchtet mir alles ein.
Ja, die Anzahl der Schleifendurchgänge ist wirklich sehr hoch (kann bis zu 1 Mrd sein).

Okay, die Schleife sieht natürlcih nicht genauso in meinem Programm aus, wollte blos zur Veranshaulischung das überspitzt darstellen.

Von daher werde ich nicht bei JEDEM Durchgang einen "SetValue" aufrufen!