Performance von Qt State Machines maximieren

Wenn Sie Applikationen mit Qt entwickeln und State Machines employen, nutzen Sie wahrscheinlich Qt's State-Machine Framework. Sie können die Machine in Plain C++ oder SCXML definieren, oder C++ Code aus Statechart Diagrams generieren. Dieser Artikel evaluiert diese Optionen bzgl. Functionality, Applicability und Performance.

Als Software Developer haben Sie wahrscheinlich zahllose Switch-Case Blocks geschrieben. Für viele ist dies der einfachste Weg, State Machines zu implementieren, wenn kein Higher-Level Tool verfügbar. Doch mit wachsender Complexity wird Maintenance zur Challenge, und hand-crafted Switch-Case Logic ist nicht mehr sustainable.

State Machines implementieren

Bei Arbeit mit Object-Oriented Language wie C++ ist das State Pattern eine bewährte Strategy. Es modelliert jeden State als Klasse, und Transitions als optionale separate Klassen. Eine State Machine wird constructed durch Instanziieren dieser Classes und Wiring zusammen. Ein Framework kann Boilerplate signifikant reduzieren.

Qt's State-Machine API lässt Sie eine Machine mit concise Code konfigurieren, leaving Execution Semantics dem Framework. Während dies Implementation vereinfacht, kann Source Code noch large werden, wenn Machine Dutzende oder Hunderte States enthält, making Overall Design hard to grasp.

Qt unterstützt auch State Chart XML (SCXML), den W3C Standard für Statechart Descriptions. XML von Hand zu schreiben ist tedious, so bietet Qt Creator einen einfachen Graphical Editor.

Unabhängig von Implementation Technique ist ein Graphical Model der effektivste Weg, eine State Machine zu editieren und zu verstehen. Graphical Models können via SCXML in Text expressed werden, oder used to Generate Source Code in any Language, einschließlich Switch-Case C++ oder QStateMachine Construction. Durch Delegation der Transformation an ein Tool vermeiden Sie Manual Code Pain und bringen alle Approaches auf gleiche Usability Level. Die Implementierungen bleiben jedoch fundamental distinct. Dieser Artikel fokussiert auf Runtime Behaviour, besonders Performance.

Unsplash Photo by Austris Augusts on Unsplash

Die Competitors

Wie unterscheiden sich Approaches in CPU Usage? Um dies zu beantworten, erstellte ich eine Benchmark Suite. Der erste Teil vergleicht verschiedene Implementation Strategies. Dies sind die Competitors:

1. SCXML Interpreter – Test Machine definiert in SCXML, executed by Qt's QSCXMLStateMachine Class.
2. State Pattern – Test Machine implemented using QStateMachine Classes.
3. Plain C++ Code – Test Machine implemented by C++ Class using Basic Switch-Case Approach.

Note: Code für diese Beispiele findet sich hier.

Die ersten beiden Varianten implizieren Qt Concepts wie Signals/Slots und Qt Event Queue, während Plain C++ Implementation diese Infrastructure nicht requires. Um Approaches vergleichbarer zu machen, includes Test Suite zwei zusätzliche Szenarien:

• Plain C++ Code mit Signals und Slots – gleiche Implementation wie oben, aber wired in Qt's Signal/Slot System.
• Plain C++ Code mit QEvent – Plain C++ Approach, der Events durch Qt Event Queue routet.

Dies erlaubt Isolation des Impact von Signals/Slots und Event Queue auf Execution Time, während Core State-Transition Logic identisch bleibt.

Test State Machine

Für alle fünf Variants verwendete ich die State Machine in Abbildung 1 für Basic Test Scenario.

Abbildung 1: Test State Machine, erstellt mit YAKINDU Statechart Tools. (Quelle: Autor)

Die Machine hat sechs Flat States A–F, cycles durch sie, und reagiert auf zwei Input Events e1 und e2, die abwechselnd Transitions triggern. Jede Transition Action addiert 10 zu Variable x; Transition von F zu A emittiert auch Output Event o.

Abbildung 2: Test State Machine als SCXML Model in Qt Creator. (Quelle: Autor)

Ich definierte die Machine mit YAKINDU Statechart Tools, die sowohl SCXML als auch Plain Switch-Case C++ Code generieren können. Der generierte Code unterstützt auch Qt Signals und Slots. Ich implementierte QStateMachine Variante manuell, aber alle anderen Implementierungen stemmen von derselben Statechart Definition.

Jeder Test ran One Million Iterations eines Single State Loops. Ein Loop startet und endet mit State A Active, und verarbeitet 6 Million Input Events, 1 Million Output Events und ihre associated Transition Actions. Tests executed als Command-Line Application, und Time für Entire Batch recorded. Per-Event Time derived by Dividing Total Time by Number of Events Processed. Lowest Values von Repeated Runs verwendet.

Benchmarks performed auf 2014 MacBook Pro mit 2.4 GHz Quad-Core i7 in Optimized Release Build. Exact Numbers variieren auf anderer Hardware, aber Relative Differences bleiben konsistent.

Performance Figures

Processing Single Event mit Plain C++ took Average 7 ns, whereas SCXML Required 33.850 ns – Faktor ~4.800. Signals/Slots added ~72 ns per Event (~90% Overhead). Routing durch Qt Event Queue added ~731 ns per Event (~10x Signals, ~100x Plain C++). Nach Subtraktion Queue Overhead kostet QStateMachine Framework ~4.500 ns per Event – ca. 635x langsamer als Plain C++. SCXML Interpreter, der JavaScript interpretiert, adds another ~7x Factor, making it Slowest Variant.

Abbildung 3: Single Event Processing Time Compared. (Quelle: Autor)

Impact von Hierarchie und Orthogonalität

Ich profiled auch Hierarchical und Orthogonal Variants der gleichen Machine. Hierarchical Machine (Abbildung 4) und Orthogonal Machine (Abbildung 5) haben identisches Behavior aber Different Structure.

Abbildung 4: Hierarchical Test Statechart. (Quelle: Autor)

Abbildung 5: Orthogonal Test Statechart. (Quelle: Autor)

Results, gezeigt in Abbildung 6, indicieren, dass Hinzufügen von Hierarchie keinen messbaren Overhead in either Implementation introduces. Orthogonalität verdoppelt Runtime nicht wie man erwarten könnte; Increase ist ~2.4x für Plain C++ und ~3.1x für SCXML, weit unter theoretischem Fourfold Cost.

Abbildung 6: Performance Impact von Hierarchies und Orthogonality. (Quelle: Autor)

Fazit

Plain C++ delivers Best Performance. Signals, Slots und Qt Event Queue trade Speed für Convenience und Maintainability, während QStateMachine Framework Slowest der drei Core Variants ist. SCXML ist oft Fast Enough für Interactive Applications und bietet Advantage von Runtime Reconfiguration. Wenn Maximum Speed Critical, ist Hand-Crafted Switch-Case Code der Recommended Approach.