Expensive instantiation of StateMachine

[pavelschon]

Expensive instantiation of StateMachine

[fgmacedo]

Hi, thanks for the feedback. It's a good goal for my effort.

I had never worked on turning the startup processing because I usually create a few instances on my use cases.

One of the setup performance costs is a unique feature that I call "dynamic dispatch", so the state machine can have multiple observers. It can handle callbacks with distinct signatures from the event being called.

No problem, I'm glad you took the time to open the issue so I can go deeper into this theme.

Best regards!

[fgmacedo]

Hi @pavelschon , thanks for reporting this! I'll run a profile and try to identify improvements. This is the first report of this nature.

Is it legal to swap the model in StateMachine?

I think It will not work because we use the model as an observer, so any reference to guards and actions are pre-cached and stored as references to the attributes. I think that its partially the cause of the initial setup costs, so in order to speed up the execution we have a cost on the setup.

[pavelschon]

Thank you for quickly digging into it and began the effort on improvements!
We had also a look at similar project pytransitions/transitions and compared the performance. The StateMachine was functionally identical in both:

• python-statemachine: create 10000 instances of StateMachine: 53 seconds on laptop
• pytransitions: create 10000 instances of StateMachine: 1.8 seconds on laptop

Due to the better performance we have to go with pytransitions, despite I like the syntax of python-statemachine more.