Long build times

[multivac61]

Hi there.

I rely heavily on your wonderful sml library for some firmware code I have written. So first of all, thank you for your amazing work 🙇‍♂️

In my code base I have several large state-machines that rarely change themselve. However, when we change anything in the code base that the state machines depend on (like say a struct that contains some state) the state-machines get compiled too, which takes around 1 minute on a brand new M1 mac with a newer clang compiler.

Is there any way to circumvent these long compilation and link times? They make working with the code super dreadful.

[krzysztof-jusiak]

Sure, could you share some more precise examples/benchmarks so that we can verify/improve the library?

[dingari]

Hi, I'm working with @multivac61 on this project.

Our state machine is quite complex, utilizing nested state machines quite heavily (at least three levels atm). We've noticed during the development that adding a level of nesting seems to really impact the build times.

I'll see if we can cook up some examples/benchmarks, but in general are there any tricks to e.g. wrap/compile the state machine once, and avoid recompiling it if there is no change to the actual state machine or its dependencies? I understand this could be non-trivial because of the heavy use of templating.

[erikzenker]

Did you try to hide the state machine behind a pointer (pimpl pattern)? By that you can hide the Implementation and dont need to compile the state machine when nothing changes.

[dingari]

Thank you for the idea @erikzenker! I wonder if you could use the pimpl pattern in an embedded context with no dynamic memory? Could you provide an example off the top of your head?

[erikzenker]

@dingari your answer is just a Google search away

[mechatheo]

Hi everyone,

first of all i love your library @krzysztof-jusiak :heart: and we heavily rely on it. We have a code generator which generates boost::sml state machines from Enterprise Architect Diagrams, which works like a charm, because your DSL syntax is so damn neat, code generation is a breeze.

However with generated code, it's really easy to design very deeply nested state machines, naturally... An anecdote: We have a package where the state machine design maybe went a little too far :sweat_smile: To build this package we need around 5 minutes, even on beefy machines. And almost all machines will start swapping and we need to increase the template recursion depth to make it compilable in the first place :joy: . In our Jenkins CI we have an extra lock, which is locked, whenever a job builds this package, because even on the build server you can't build more then one of them in parallel. So it's pretty bad. And as you guys can imagine this is a thing which is just never gets fixed, because it just woks :tm:

So my question: are there some general guidelines to improve the compile time, aside from avoiding nested state machines. Also can we leverage some c++20 features to improve things, at least for newer compilers? Any pointers or help would be appreciated.

[krzysztof-jusiak]

Thanks, @mechatheo. I'm happy to optimize compliation times, especially with C++20 we have tons of options available but as always it depends on the use case. If you could please provide some representative generated code example which compiles a long time and I could iterate on, that would be fantastic. Thanks.

[mechatheo]

Hey @krzysztof-jusiak i've sent you an email with a code package, to have a look at. Thank you very much!