Improve compile times

[iliekturtles]

Compiling uom with all features enabled takes a significant amount of time. -Ztime-passes shows that the issue is in privacy checking:

$ RUSTFLAGS="-Ztime-passes" cargo +nightly test --no-run
...
time: 172.929; rss: 507MB	privacy checking
...

Timing for this pass increases linearly with the number of underlying storage types enabled. Enabling features for underlying storage types adds impl blocks and type aliases for existing types. No new types are added. Additionally, all structs and traits are pub in uom.

The graph below shows compile times, as reported by cargo for test --no-run in blue and build in red:

Test	Build	Features
15.74	5.5	f64
20.4	5.43	f32,f64
38.84	6.24	bigrational,f32,f64
37.75	7.4	rational64,bigrational,f32,f64
48.28	8.26	rational32,rational64,bigrational,f32,f64
55.52	9.26	rational,rational32,rational64,bigrational,f32,f64
67.57	10.89	biguint,rational,rational32,rational64,bigrational,f32,f64
96.81	12.5	bigint,biguint,rational,rational32,rational64,bigrational,f32,f64
94.53	15.21	i64,bigint,biguint,rational,rational32,rational64,bigrational,f32,f64
106.92	16.4	i32,i64,bigint,biguint,rational,rational32,rational64,bigrational,f32,f64
116.34	18.17	i16,i32,i64,bigint,biguint,rational,rational32,rational64,bigrational,f32,f64
131.29	20.2	i8,i16,i32,i64,bigint,biguint,rational,rational32,rational64,bigrational,f32,f64
144.3	22.19	isize,i8,i16,i32,i64,bigint,biguint,rational,rational32,rational64,bigrational,f32,f64
137.48	24.67	u64,isize,i8,i16,i32,i64,bigint,biguint,rational,rational32,rational64,bigrational,f32,f64
158.4	26.93	u32,u64,isize,i8,i16,i32,i64,bigint,biguint,rational,rational32,rational64,bigrational,f32,f64
194.9	29.69	u16,u32,u64,isize,i8,i16,i32,i64,bigint,biguint,rational,rational32,rational64,bigrational,f32,f64
211.47	33.53	u8,u16,u32,u64,isize,i8,i16,i32,i64,bigint,biguint,rational,rational32,rational64,bigrational,f32,f64
198.5	36.63	usize,u8,u16,u32,u64,isize,i8,i16,i32,i64,bigint,biguint,rational,rational32,rational64,bigrational,f32,f64

[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.

[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.

[iliekturtles]

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

[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]

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]

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