qtforum.de

Hallo,
ich arbeite hier an einem größeren Projekt, Es handelt sich um optimierungssoftware. Ich habe dafür ein grafische Auswertungstool mittels QT geschrieben. Nun soll die Optimierung aus dieser Oberfläche gestartet werden und zwar nicht nur als externe Exe, sonder als integrierte Anwendung.
Ich habe es zuerst mit QThreads versucht. Also in dem Thread die Main des anderen Programm gestartet. Das Programm lief um Faktor 20 langsamer. Nun habe ich es nochmals mit Boost Threads probiert. Zwar ist eine leiche Besserung zu spüren, allerdings steckt da immer noch bestimmt Faktor 12 hinter. Die GUI macht (bisher) in der Zeit nichts, ausser ab und zu umgeleitete couts zu in einem Textfenster zu protokolloeren.

Leider darf ich hier keinen Quellcode posten. Ich denke auch nicht das es an der Implementierung direkt liegt, habe schon sehr viele multithread Anwendungen mit Boost geschrieben und eigentlich lief das immer top.

Meine Idee ist folgende:
Die Optimierungssoftware ist aus dem Jahr 2000 und benutzt dementsprechend noch veraltete STLs. Sie macht massiv gebrauch von Listen (std::list), kann es sein dass durch die verwendung von QT in meinem Projekt irgendwelche anderen STLs benutzt werden, wo die Listen enorm langsam sind? Meine ersten Zeitmessung deuten zumindest darauf hin. Eine Punkteliste aus 300 Punkten die lediglich mulitpliziert werden, brauchen fast 5 mal so lange wie normal.

Gruß
Sebastian

Weil mir keine besonders schnelle oder langsame (STL-)Templates bekannt sind und ein Thread einfach ein Thread ist (ein "while(1);" belegt einfach ein Core zu 100%), würde ich möglichst methodisch vorgehen:

1. Laufzeit der alten (original) Binary messen: (Unix: "time mybinary").
2. Mit dem aktuellen Entwicklungssystem (gcc/mingw/ms oder was auch immer) komplett Qt-frei (z.B. eigene Makefile) compilen und nochmals messen
3. In einem Qt-Projekt compilen (mit pro-File und QCoreApplication im main()) und nochmals messen, wobei nun nicht mehr der komplette Programmablauf (QCoreApplication sucht sich beim Start die Plugins zusammen) gemessen werden darf, sondern nur noch die eigentliche Aktion (mittels QTime oder sonst einem Highresolution-Timer messen).
4. In einer Qt-Konsolenapplikation ein Thread (mit der Optimierungssoftware) starten (wobei der Konsolen-Haupt(thread) nichts tut)
5. Komplett mit Qt-GUI, allenfalls mit und ohne Datenaustausch zwischen GUI und Thread.

solche Sachen wie "Die GUI macht (bisher) in der Zeit nichts, ausser ab und zu umgeleitete couts zu in einem Textfenster zu protokolloeren. " sollte man logischerweise erst _nach_ den Testmessungen hinzufügen...

Unter Unix sind boost sowie QThread nur Wrapper um pthreads, ist daher unwahrscheinlich dass die "Qt threads" langsamer sind.
Was ich mir vorstellen könnte, ist, dass boost und Qt unterschiedliche Thread-Eigenschaften setzen (priority, scheduling usw).

Bist du sicher, dass nicht doch deine Gui dir ins Süppchen spuckt? Machs doch mal wie von solarix vogeschlagen, nimm ne leere main() und pack in nen nackten QThread deine Applikation, und versuchs nochmal.

Erstmal danke für eure Antworten.

Ich arbeite auf Windows XP, sorry, hatte ich vergessen anzugeben. Habe die Thread Priorittät überprüft, steht auf 8, genau wie die Qt Applikation ansich. Ich glaube auch nicht, dass QThreads langsamer sind als Boost Threads, aber ich brauche ne Alternative um den Faktor auszuschließen.

Also ich habe alle Ausgaben in der GUI deaktiviert und ne Zeitmessung vorgenommen, die Unterschiede liegen, je nach Populationgröße der Optimierung, zwischen 4 und 10 facher Einbusse gegenüber dem standalone Programm.

Wir reden hier von 1 GB Quellcode, mal eben ein neues Qt Projekte mit allen Includes, Libs und weitern Einstellungen zu machen ist leider nicht drinne bzw. wirklich meine aller letzte Alternative.

Kurios ist halt wirklich, dass die meiste Zeit bei diesen std::list Zugriffen flöten geht. Kann das vielleicht was mit dem Heap oder Stack eines Threads zu tun haben?

Ich probiere gleich mal das alte Projekt als Thread zu starten, vielleicht komme ich ja so dahinter was es damti auf sich hat.

Bin für weitere Vorschläge offen.

GrooveXT hat geschrieben: Wir reden hier von 1 GB Quellcode, mal eben ein neues Qt Projekte mit allen Includes, Libs und weitern Einstellungen zu machen ist leider nicht drinne bzw. wirklich meine aller letzte Alternative.

Die stelle mit "myThread = new MyThread(); myThread->run()" solltest du doch recht einfach, im vorhandenen Projekt, in deine main.cpp verlagern können, und dort den Rest auskommentieren.

So, also ich habe das Ursprungsprojekt in Threads verpackt und lieft genauso schnell wie vorher. Also keine Geschwindigkeitseinbußen.

pfid hat geschrieben:

GrooveXT hat geschrieben: Wir reden hier von 1 GB Quellcode, mal eben ein neues Qt Projekte mit allen Includes, Libs und weitern Einstellungen zu machen ist leider nicht drinne bzw. wirklich meine aller letzte Alternative.

Die stelle mit "myThread = new MyThread(); myThread->run()" solltest du doch recht einfach, im vorhandenen Projekt, in deine main.cpp verlagern können, und dort den Rest auskommentieren.

Danach habe ich deinen Rat befolgt und den Inhalt der Main des Qt Projekt auskommentiert. Dort habe ich dann die Main der Optimierung aufgerufen, einmal als eigentständigen Thread und einmal direkt als Funktionsaufruf. Beides mal wieder diese enttäuschenden Ergebnisse. Mittlerweile sind, warum auch immer, die Timings sogar noch schlechter geworden.

Langsam gehen mir die Ideen aus...

So nochmal ich.

Ich habe den Fehler gefunden. Es lag an Visual Studio. Ich habe die Release Version kompiliert und in der IDE ausgeführt. Kopiere ich die Exe in einen spearaten Ordner mit allen dlls, läuft alles einwandfrei und genauso schnell wie das alte Projekt. Kapiere zwar nicht warum, denn das alte Projekt läuft in IDE und standalone gleich schnell. Naja wieder nen halben Tag für umsonst.

Vielen dank für eure Hilfe.

Gruß
Sebastian