Maximizando Performance de Máquinas de Estado Qt

Se você desenvolve aplicações com Qt e emprega máquinas de estado, provavelmente usa o framework de máquina de estado do Qt. Você pode definir a máquina em C++ puro ou SCXML, ou gerar código C++ a partir de diagramas state-chart. Este artigo avalia estas opções em termos de funcionalidade, aplicabilidade e performance.

Como desenvolvedor de software, você provavelmente escreveu incontáveis blocos switch-case. Para muitos, esta é a maneira mais simples de implementar máquinas de estado quando nenhuma ferramenta de nível superior está disponível. No entanto, à medida que a complexidade cresce, manutenção se torna um desafio, e lógica switch-case artesanal não é mais sustentável.

Implementando máquinas de estado

Quando trabalhando com uma linguagem orientada a objetos como C++, o state pattern é uma estratégia comprovada. Ele modela cada estado como uma classe, e transições como classes separadas opcionais. Uma máquina de estado é construída criando instâncias destas classes e conectando-as. Um framework pode reduzir significativamente boilerplate.

A API de máquina de estado do Qt permite configurar uma máquina com código conciso, deixando a semântica de execução para o framework. Embora isso simplifique implementação, o código-fonte ainda pode crescer grande quando uma máquina contém dezenas ou centenas de estados, tornando o design geral difícil de compreender.

Qt também suporta State Chart XML (SCXML), o padrão W3C para descrições de state-chart. Escrever XML à mão é tedioso, então o Qt Creator oferece um editor gráfico simples.

Independente da técnica de implementação, um modelo gráfico é a maneira mais eficaz de editar e entender uma máquina de estado. Modelos gráficos podem ser expressos em texto via SCXML, ou usados para gerar código-fonte em qualquer linguagem, incluindo switch-case C++ ou construção QStateMachine. Delegando a transformação a uma ferramenta, você evita a dor do código manual e traz todas as abordagens ao mesmo nível de usabilidade. As implementações, no entanto, permanecem fundamentalmente distintas. Este artigo foca em comportamento de runtime, especialmente performance.

UnsplashPhoto by Austris Augusts on Unsplash

Os competidores

Como as abordagens diferem em uso de CPU? Para responder, criei uma suite de benchmarks. A primeira parte compara as diferentes estratégias de implementação. Estes são os competidores:

1. Intérprete SCXML — a máquina de teste é definida em SCXML e executada pela classe QSCXMLStateMachine do Qt.
2. State pattern — a máquina de teste é implementada usando classes QStateMachine.
3. Código C++ puro — a máquina de teste é implementada por uma classe C++ que usa abordagem básica switch-case.

Nota: Código para estes exemplos pode ser encontrado aqui.

As duas primeiras variantes implicam uso de conceitos Qt como signals e slots bem como uso de uma event queue do Qt, enquanto uma implementação C++ pura não requer esta infraestrutura. Para tornar as abordagens mais comparáveis, a suite de testes inclui dois cenários adicionais:

• Código C++ puro com signals e slots — a mesma implementação acima mas conectada ao sistema signal/slot do Qt.
• Código C++ puro com QEvent — a abordagem C++ pura que roteia eventos através da event queue do Qt.

Isso nos permite isolar o impacto de signals/slots e da event queue no tempo de execução mantendo a lógica de transição de estado idêntica.

A máquina de estado de teste

Para todas as cinco variantes usei a máquina de estado ilustrada na Figura 1 para o cenário de teste básico.

Figura 1: A máquina de estado de teste, como criada com YAKINDU Statechart Tools. (Fonte: Autor)

A máquina tem seis estados flat A–F, cicla através deles e reage a dois eventos de entrada e1 e e2 que alternadamente disparam transições. Cada ação de transição adiciona 10 a uma variável x; a transição de F para A também emite o evento de saída o.

Figura 2: A máquina de estado de teste como modelo SCXML no Qt Creator. (Fonte: Autor)

Defini a máquina com YAKINDU Statechart Tools, que pode gerar tanto SCXML quanto código C++ switch-case puro. O código gerado também suporta Qt signals e slots. Implementei a variante QStateMachine manualmente, mas todas as outras implementações derivam da mesma definição de state-chart.

Cada teste rodou um milhão de iterações de um único loop de estado. Um loop inicia e termina com estado A ativo, e processa 6 milhões de eventos de entrada, 1 milhão de eventos de saída e suas ações de transição associadas. Os testes foram executados como aplicação de linha de comando, e o tempo para o batch inteiro foi registrado. O tempo por evento foi derivado dividindo o tempo total pelo número de eventos processados. Os menores valores de execuções repetidas foram usados.

Benchmarks foram realizados em um MacBook Pro 2014 com quad-core i7 de 2.4 GHz em build release otimizado. Números exatos variarão em outro hardware, mas diferenças relativas permanecem consistentes.

Figuras de performance

Processar um único evento com C++ puro levou média de 7 ns, enquanto SCXML requereu 33.850 ns — um fator de cerca de 4.800. Usar signals e slots adicionou ~72 ns por evento (~90% overhead). Roteamento através da Qt event queue adicionou ~731 ns por evento (~10x signals, ~100x C++ puro). Subtraindo overhead da queue, o framework QStateMachine custa ~4.500 ns por evento — aproximadamente 635x mais lento que C++ puro. O intérprete SCXML, que interpreta JavaScript, adiciona outro fator ~7x, tornando-o a variante mais lenta.

Figura 3: Tempo de processamento de evento único comparado. (Fonte: Autor)

Impacto de hierarquia e ortogonalidade

Também perfilhei variantes hierárquicas e ortogonais da mesma máquina. A máquina hierárquica (Figura 4) e a máquina ortogonal (Figura 5) têm comportamento idêntico mas estrutura diferente.

Figura 4: Statechart de teste hierárquico. (Fonte: Autor)

Figura 5: Statechart de teste ortogonal. (Fonte: Autor)

Resultados, mostrados na Figura 6, indicam que adicionar hierarquia não introduz overhead mensurável em nenhuma implementação. Ortogonalidade também não dobra o runtime como se poderia esperar; o aumento é cerca de 2,4x para C++ puro e 3,1x para SCXML, bem abaixo do custo teórico de quatro vezes.

Figura 6: Impacto de performance de hierarquias e ortogonalidade. (Fonte: Autor)

Conclusão

C++ puro entrega a melhor performance. Signals, slots e a Qt event queue trocam velocidade por conveniência e manutenibilidade, enquanto o framework QStateMachine é o mais lento das três variantes principais. SCXML é frequentemente rápido o suficiente para aplicações interativas e oferece a vantagem de reconfiguração em runtime. Quando velocidade máxima é crítica, código switch-case artesanal é a abordagem recomendada.