Langsame Qt-Anwendung: Diagnose beauftragen und Verbesserung prüfen
Wenn eine Qt-Anwendung langsamer wird oder nicht mehr reagiert, sollten Sie zunächst einen konkreten Arbeitsablauf nachstellen und messen, wo die Zeit verloren geht. Erst die Diagnose zeigt, ob der Datenabruf, das Verhalten der Oberfläche oder die Berechnungen geändert werden sollten. Legen Sie bei der Beauftragung auch fest, wie die Verbesserung unter Bedingungen geprüft wird, die dem Arbeitsalltag entsprechen: mit einem passenden Rechner und repräsentativen Daten.
Für Produktverantwortliche sind zwei Ziele zu unterscheiden: Der Vorgang soll früher abgeschlossen sein, und die Anwendung soll währenddessen reagieren. Ein Fenster lässt sich bedienbar machen, ohne den gesamten Import zu verkürzen. Umgekehrt kann ein kürzerer Import weiterhin eine Phase enthalten, in der Nutzer nichts tun können. Klären Sie, welches Problem die Arbeit des Teams beeinträchtigt.
Beschreiben Sie das Problem so, dass es reproduzierbar ist
„Das Programm ist langsam“ reicht nicht aus, um den Aufwand einer Korrektur zu schätzen. Beschreiben Sie den Ablauf: Mit welchem Klick beginnt die Wartezeit, was sehen Nutzer währenddessen und woran erkennen sie das Ende? Halten Sie Anwendungsversion, Betriebssystem, Rechner sowie Art und Umfang der Daten fest. Ergänzen Sie, ob das Problem immer, beim ersten Start oder erst nach mehreren Stunden auftritt.
Betrifft die Verzögerung nur einzelne Arbeitsplätze, gehört deren Vergleich zur Diagnose. Ein Test auf dem schnelleren Rechner des Dienstleisters reproduziert das gemeldete Problem möglicherweise nicht. Ebenso ersetzt eine kleine Testdatei nicht das Dokument, bei dem Beschäftigte tatsächlich warten müssen. Testdaten sollten die für das Problem relevanten Eigenschaften behalten. Achten Sie bei der Anonymisierung darauf, diese nicht versehentlich zu entfernen.
In dieser Phase können Sie eine Untersuchung mit begrenztem Umfang beauftragen. Sie sollte das reproduzierte Problem, Messungen, eine ermittelte Ursache oder klar benannte fehlende Informationen sowie einen Vorschlag für die nächsten Arbeiten liefern. So haben Sie eine Grundlage für die Budgetentscheidung, bevor Ihr Unternehmen einer pauschalen „Optimierung der gesamten Anwendung“ zustimmt.
Klären Sie, worauf die Anwendung tatsächlich wartet
Der Dienstleister sollte die Zeiten für Datenabruf, Berechnungen und den Aufbau der Ansicht getrennt erfassen. Dabei hilft Profiling: Es misst, welche Teile des Programms Arbeit ausführen und wie viel Zeit sie beanspruchen. Die Qt-Quick-Dokumentation empfiehlt Profiling vor der Auswahl von Optimierungen, damit die Arbeit am tatsächlichen Problem ansetzt.
Das Werkzeug muss zur Anwendung passen. Der QML Profiler in Qt Creator hilft bei der Analyse von Oberflächen mit QML und JavaScript, führt aber kein Profiling des C++-Codes durch. Ein Diagramm dieses Werkzeugs allein erklärt daher nicht jede Verzögerung in einer Qt-Anwendung. Bitten Sie um einen Befund zum gemeldeten Ablauf: Was verzögert ihn, und welche Messung belegt das?
Wartet das Programm auf die Antwort eines externen Systems, verkürzt eine Änderung an der Darstellung von Schaltflächen diese Wartezeit möglicherweise nicht. Sind die Daten bereits vorhanden, erscheinen aber erst spät, muss der Aufbau der Ansicht untersucht werden. Trotz eines ähnlichen Symptoms auf dem Bildschirm sind das unterschiedliche Arbeitsaufträge. Der Befund sollte aus den Beobachtungen folgen, statt Qt als Ursache vorauszusetzen.
Prüfen Sie die Bedienbarkeit während des Vorgangs gesondert
In Qt lassen sich längere Arbeiten von dem Programmteil trennen, der die Oberfläche bedient. Die Anzeige des Ergebnisses muss weiterhin die Regeln für die Arbeit mit der Oberfläche im Hauptthread berücksichtigen. Diese Trennung beschreibt die Qt-Dokumentation zu Threads und Objekten. Für Sie als Auftraggeber zählt, wie sich das Programm während der Ausführung verhält.
Eine aufwendige Operation später zu starten bedeutet noch nicht, dass sie im Hintergrund läuft. QTimer legt den Zeitpunkt eines Aufrufs fest und verlagert die Arbeit nicht automatisch in einen anderen Thread. Erscheint das Fenster bei einer Vorführung schnell und friert dann ein, prüfen Sie den gesamten Ablauf.
Legen Sie fest, ob eine Fortschrittsanzeige, ein Abbruch des Vorgangs und das sichere Schließen des Fensters erforderlich sind. Vereinbaren Sie auch, was mit teilweise ausgeführten Änderungen geschieht. Eine Schaltfläche „Abbrechen“, nach deren Nutzung der Datenstand unklar bleibt, ist kein ausreichendes Ergebnis der Korrektur.
Beispiel: eine Datei in eine Qt-Anwendung importieren
Nehmen wir hypothetisch an, ein Mitarbeiter wählt eine Datei zum Import aus. Anschließend reagiert das Fenster nicht mehr, bis die Ergebnisse erscheinen. Messen Sie vor der Änderung getrennt die Zeit bis zur Datenanzeige und den Zeitraum ohne Reaktion auf Benutzereingaben. Prüfen Sie außerdem, ob sich das Verhalten bei einer Wiederholung desselben Ablaufs ändert.
Zeigt die Messung, dass der Import die Oberfläche blockiert, kann die Korrektur darin bestehen, diese Arbeit getrennt auszuführen und Fortschritt sowie Ergebnis zu übermitteln. Zur Abnahme gehören ein vollständig abgeschlossener Import, ein Abbruchversuch und das Verhalten bei einem Dateifehler. Liegt die Ursache dagegen beim Datenabruf von einem Server, ist ein anderer Arbeitsumfang nötig. Das Beispiel veranschaulicht die Entscheidung; es ist kein Testergebnis eines konkreten Produkts.
Vergleichen Sie am Ende sowohl die Dauer und Bedienbarkeit als auch die Richtigkeit der importierten Daten. Ein schneller sichtbares Fenster mit unvollständigem Ergebnis erfüllt nicht dieselbe Anforderung wie ein korrekt abgeschlossener Vorgang.
Vergleichen Sie Ergebnisse unter denselben Bedingungen
Der Bericht nach der Korrektur sollte die Anwendungsversionen vor und nach der Änderung, Rechner, Betriebssystem, Daten und Testablauf nennen. Trennen Sie den ersten Durchlauf von späteren, bei denen das Programm möglicherweise bereits geladene Informationen nutzt. Wiederholen Sie den Ablauf, damit ein einzelnes günstiges Ergebnis nicht die Beurteilung des Arbeitsalltags ersetzt.
Die Ausführungsbedingungen sollten vergleichbar sein, auch hinsichtlich aktivierter Messwerkzeuge. Erfordert die Diagnose eine andere Programmkonfiguration, sollte der Dienstleister den Unterschied erklären und zusätzlich die für Nutzer vorgesehene Version prüfen.
Messen Sie das ursprüngliche Problem. Bei einem langsamen Start ist das die Zeit, bis sich die benötigte Aufgabe erledigen lässt. Bei einem blockierten Fenster ist es die Reaktion auf Benutzereingaben. Verschlechtert sich die Leistung im Tagesverlauf, zählt das Verhalten nach wiederholten Vorgängen. Prozessor- und Speicherauslastung können die Diagnose unterstützen, ersetzen aber nicht das Ergebnis der eigentlichen Aufgabe.
Prüfen Sie vor der Einführung auch Funktionen, die von der Korrektur betroffen sein könnten, etwa Speichern, Filtern oder Drucken. Verändert sie die Datenspeicherung oder den Ablauf eines Vorgangs, vereinbaren Sie die Voraussetzungen für eine Rückkehr zur vorherigen Version. Der Prüfumfang sollte sich an der Änderung orientieren und nicht an einer beliebigen Liste aller Qt-Funktionen.
Was sollte der Dienstleister übergeben?
Neben der neuen Programmversion benötigen Sie eine kurze Erklärung der Ursache, der vorgenommenen Änderungen und der Vergleichsergebnisse. Es sollte klar sein, welche Bedingungen geprüft wurden, welche Einschränkungen bleiben und wer das Verhalten nach der Einführung beobachtet. Bewahren Sie den verwendeten Testablauf für spätere Versionen auf, damit dasselbe Problem nicht unbemerkt zurückkehrt.
Nehmen Sie die Korrektur anhand der zuvor vereinbarten Nutzeranforderung ab. Ein prozentuales Geschwindigkeitsversprechen ohne Angaben zu Aufgabe, Daten und Messbedingungen sagt nicht aus, ob Beschäftigte ihre Arbeit damit zügiger erledigen können.
