Maximizando rendimiento de máquinas de estado Qt

Si desarrollas aplicaciones con Qt y empleas máquinas de estado, probablemente usas el framework de máquina de estado de Qt. Puedes definir la máquina en C++ plano o SCXML, o generar código C++ desde diagramas state-chart. Este artículo evalúa estas opciones en términos de funcionalidad, aplicabilidad y rendimiento.

Como desarrollador de software, probablemente has escrito incontables bloques switch-case. Para muchos, esta es la forma más simple de implementar máquinas de estado cuando no hay herramienta de alto nivel disponible. Sin embargo, a medida que crece la complejidad, el mantenimiento se vuelve un reto, y la lógica switch-case artesanal ya no es sostenible.

Implementando máquinas de estado

Cuando trabajas con lenguaje orientado a objetos como C++, el state pattern es una estrategia probada. Modela cada estado como una clase, y transiciones como clases separadas opcionales. Una máquina de estado se construye creando instancias de estas clases y cableándolas juntas. Un framework puede reducir significativamente boilerplate.

La API de máquina de estado de Qt te permite configurar una máquina con código conciso, dejando la semántica de ejecución al framework. Aunque esto simplifica implementación, el código fuente puede crecer mucho cuando una máquina contiene docenas o cientos de estados, dificultando la comprensión del diseño global.

Qt también soporta State Chart XML (SCXML), el estándar W3C para descripciones de state-chart. Escribir XML a mano es tedioso, así que Qt Creator ofrece un editor gráfico simple.

Independientemente de la técnica de implementación, un modelo gráfico es la forma más efectiva de editar y entender una máquina de estado. Modelos gráficos pueden expresarse en texto vía SCXML, o usarse para generar código fuente en cualquier lenguaje, incluyendo switch-case C++ o construcción QStateMachine. Delegando la transformación a una herramienta, evitas el dolor de código manual y llevas todos los enfoques al mismo nivel de usabilidad. Las implementaciones, sin embargo, permanecen fundamentalmente distintas. Este artículo se enfoca en comportamiento en runtime, especialmente rendimiento.

Unsplash Photo by Austris Augusts on Unsplash

Los competidores

¿Cómo difieren los enfoques en uso de CPU? Para responder, creé una suite de benchmarks. La primera parte compara las diferentes estrategias de implementación. Estos son los competidores:

1. Intérprete SCXML – la máquina de test se define en SCXML y ejecuta por clase QSCXMLStateMachine de Qt.
2. State pattern – la máquina de test se implementa usando clases QStateMachine.
3. C++ plano – la máquina de test se implementa por una clase C++ que usa enfoque básico switch-case.

Nota: Código para estos ejemplos puede encontrarse aquí.

Las dos primeras variantes implican uso de conceptos Qt como signals y slots y uso de cola de eventos Qt, mientras que una implementación C++ plano no requiere esta infraestructura. Para hacer los enfoques más comparables, la suite de test incluye dos escenarios adicionales:

• C++ plano con signals y slots – la misma implementación de arriba pero cableada al sistema signal/slot de Qt.
• C++ plano con QEvent – el enfoque C++ plano que enruta eventos a través de la cola de eventos Qt.

Esto permite aislar el impacto de signals/slots y la cola de eventos en tiempo de ejecución manteniendo la lógica core de transición de estado idéntica.

La máquina de estado de test

Para las cinco variantes usé la máquina de estado ilustrada en Figura 1 para el escenario de test básico.

Figura 1: La máquina de estado de test, creada con YAKINDU Statechart Tools. (Fuente: Autor)

La máquina tiene seis estados planos A–F, cicla a través de ellos, y reacciona a dos eventos de entrada e1 y e2 que disparan transiciones alternadamente. Cada acción de transición suma 10 a una variable x; la transición de F a A también emite evento de salida o.

Figura 2: La máquina de estado de test como modelo SCXML en Qt Creator. (Fuente: Autor)

Definí la máquina con YAKINDU Statechart Tools, que puede generar tanto SCXML como código C++ switch-case plano. El código generado también soporta Qt signals y slots. Implementé la variante QStateMachine manualmente, pero todas las otras implementaciones derivan de la misma definición de state-chart.

Cada test corrió un millón de iteraciones de un solo bucle de estado. Un bucle inicia y termina con estado A activo, y procesa 6 millones de eventos de entrada, 1 millón de eventos de salida y sus acciones de transición asociadas. Los tests se ejecutaron como aplicación de línea de comandos, y el tiempo para el lote completo se registró. El tiempo por evento se derivó dividiendo el tiempo total por el número de eventos procesados. Se usaron los valores más bajos de ejecuciones repetidas.

Benchmarks se realizaron en un MacBook Pro 2014 con 2.4 GHz quad-core i7 en build release optimizado. Números exactos variarán en otro hardware, pero diferencias relativas permanecen consistentes.

Figuras de rendimiento

Procesar un solo evento con C++ plano tomó promedio 7 ns, mientras SCXML requirió 33 850 ns —un factor de ~4 800. Usar signals y slots añadió ~72 ns por evento (~90 % overhead). Enrutar a través de la cola de eventos Qt añadió ~731 ns por evento (~10× signals, ~100× C++ plano). Restando overhead de cola, el framework QStateMachine cuesta ~4 500 ns por evento —aprox 635× más lento que C++ plano. El intérprete SCXML, que interpreta JavaScript, añade otro factor ~7×, haciéndolo la variante más lenta.

Figura 3: Tiempo de procesamiento de evento único comparado. (Fuente: Autor)

Impacto de jerarquía y ortogonalidad

También perfilé variantes jerárquicas y ortogonales de la misma máquina. La máquina jerárquica (Figura 4) y la máquina ortogonal (Figura 5) tienen comportamiento idéntico pero estructura diferente.

Figura 4: Statechart jerárquico de test. (Fuente: Autor)

Figura 5: Statechart ortogonal de test. (Fuente: Autor)

Resultados, mostrados en Figura 6, indican que añadir jerarquía no introduce overhead medible en ninguna implementación. Ortogonalidad tampoco duplica el runtime como cabría esperar; el aumento es ~2.4× para C++ plano y ~3.1× para SCXML, muy por debajo del coste teórico cuádruple.

Figura 6: Impacto de rendimiento de jerarquías y ortogonalidad. (Fuente: Autor)

Conclusión

C++ plano entrega el mejor rendimiento. Signals, slots y cola de eventos Qt intercambian velocidad por conveniencia y mantenibilidad, mientras que el framework QStateMachine es el más lento de las tres variantes core. SCXML es a menudo lo suficientemente rápido para aplicaciones interactivas y ofrece ventaja de reconfiguración en runtime. Cuando la velocidad máxima es crítica, código switch-case artesanal es el enfoque recomendado.