Improve compile times

[iliekturtles]

Improve compile times

[iliekturtles]

I pushed 224db41 recently that makes a big dent in the problem! The issue is related to private type aliases of public types. Making the type alias public cuts a clean build with --all-features from 1137.24 s down to 28.68 s on one of my machines! A build with default features goes from 25.94 s to 5.73 s.

I did eventually get cargo bloat running after some technical delays and and the results seem to show that uom, at least for the si example, is fully inlined: https://gist.github.com/iliekturtles/474e950b544c268d3c600567f0f60bd8.

I'm leaving the issue open for the moment as I want to submit a report upstream.

[iliekturtles]

Initial investigation shows that the storage_types! calls in quantity! that add $crate::Conversion<V> and super::Conversion<V> impl blocks are the culprit. Commenting out these impls makes compilation significantly faster.

[iliekturtles]

I'm pretty sure macro recursion isn't the issue, but reviewing the output of cargo bloat is a good idea!

[juleskers]

(Hi from the 'what are you up to this week' thread)

Maybe this blogpost about claps weight-reduction can help?
https://clap.rs/2018/01/09/new-years-weight-loss/ (sorry, the title sounds a bit spammy)
This uses the excellent cargo bloat), which helped kbknapp see where his macros where unexpectedly recursing, and some refactoring brought down the total code size (and thus, compile time).

Admittedly, the blog is mostly about binary size, but on the assumption that "more generated code == more compile time", it might pay to have a look.

[juleskers]

Yeah, from the issue description, and the mostly linear time relation with the number of enabled features (excellent benchmark, b.t.w.), it's probably just the linear amount of complex implementations.

But who knows, maybe bloat can help you identify some potential optimisations in those traits. :-)

[iliekturtles]

Closing this issue. Upstream issue triaged and current uom compile times are reasonable.