parallelise the code-gen

[danieleades]

inspired by @GabrielDertoni's work in #161, this PR provides a (much more modest) performance boost by parallelising the code-gen using rayon

[danieleades]

open questions-

• does rayon provide a speed up on all targets, or only some?
• is it worth feature-gating this?

[GabrielDertoni]

I would like to see how this does after #161 gets merged. Maybe the 1.84s of rayon comp time will already make it not worth it.

[patrickelectric]

Just some unnecessary style change to approve this, everything else looks awesome.

[patrickelectric]

do not follow up style changes with funcional changes as well, having such list in a huge single line is harder to maintain.

[danieleades]

no problem. This was introduced as an artefact of using cargo edit to add the rayon dependency (which can change formatting), not an intentional change

[danieleades]

I would like to see how this does after #161 gets merged. Maybe the 1.84s of rayon comp time will already make it not worth it.

I agree it's worth merging your changes first and then reassessing.

I think also it maybe be worth considering initial compilation and subsequent compilation separately. For example maybe its worth compiling rayon once to get a benefit on every subsequent recompilation of this library

[danieleades]

@GabrielDertoni on my machine, rayon costs 2.79s, in order save 1.2seconds to run the mavlink build script. On that basis it's not worth it for downstream users of this crate. It would be beneficial for developers on this crate who are recompiling repeatedly, but you're talking a 1 second improvement on a total compile time of around 60seconds, so it's a marginal gain.

I suspect the change isn't worth it on that basis, unless there's a more lightweight way to parallelise this without rayon.

[GabrielDertoni]

Yes, well maybe there are some other ways to more significantly improve compilation speed. In particular in my measurements removing the serde reduces mavlink compilation time to ~1/3. If you additionally only have the common feature enabled instead of ardupilotmega it gets to ~1/6 the time. So, although it would be a breaking change, it would be good to eventually remove these from the default featues since they aren't even required for the tests to run.

[GabrielDertoni]

Another way to significantly improve developer experience for this crate is using a separate crate for codegen, and letting it run build/parse.rs and including the generated code. This way, developers that don't want to change the parser, don't need to wait for the build script to rerun and all the exact same generated code to get compiled once again.