Tweak source to improve compile times

[alexcrichton]

I've noticed that the winapi crate takes quite a long time to compile and seeing how it's at the base of many projects it would be nice to give it a nice compile time enhancement! There are a few changes which I've found which can easily get some nice compile-time wins:

• Move #[derive(Debug)] behind a feature gate. This is very rarely actually used and otherwise is just lots of code bloat/generation.
• Don't use #[derive(Clone)] but instead always manually implement using *self. This is easier on codegen as there are simply fewer statements to deal with.

On the more difficult side of things:

• As winapi is at the base of the dependency tree, it may make sense to move out a number of impl blocks (e.g. anything requiring codegen) to external crates (e.g. opt-in). Adding layers of abstraction may be best suited for further crates rather than the bare-bones-base.

The timings I've found are below, and as you go down the table the effects are cumulative:

modification	dbg	opt
none	24.129	36.594
remove Debug	13.855	18.058
custom Clone	10.772	13.128
remove impl	7.176	8.385

e.g. with some simple changes which shouldn't affect usability much, this library can compile ~4x faster.

[retep998]

it may make sense to move out a number of impl blocks (e.g. anything requiring codegen) to external crates (e.g. opt-in)

How would I move impl blocks to a separate crate? Don't trait impls have to be in the same crate as either the type or the trait?

Move #[derive(Debug)] behind a feature gate.

I'd have to add an equivalent feature flag to all the -sys crates since otherwise someone could end up with the -sys crates using a different version of winapi than what upstream is using causing compile errors.

Don't use #[derive(Clone)] but instead always manually implement using *self.

I'll probably handle this with a STRUCT! macro.

[alexcrichton]

Right, there are questions in making these changes, and it won't be the exact same crate as it is today (e.g. you of course can't "just move" the impls to another crate). I think the that a 70% faster compile time for not worrying about a feature that's probably not used 70% of the time is probably worth it, however.

I don't think there'd be a worry about multiple versions of winapi as if features are used then Cargo will union features and still only compile winapi once. This means if someone enables the debug feature it'll take longer to compile winapi but that's it.

FWIW I've also been exploring a macro solution for the libc rewrite as well.

[alexcrichton]

ping? Any update on this?

[retep998]

Most structs have been switched to STRUCT! which uses the custom Clone impl already. I'll make the Debug impl an opt-out feature soon, and then for 0.3 I'll switch it to being an opt-in feature.

[alexcrichton]

Any update on this? A debug compile of this library still takes upwards of 30 seconds, which seems crazy when other FFI binding crates, like libc, take less than a second to compile.

[retep998]

I will be gone next week and after that I will renew my focus on winapi 0.3 to clean up the -sys crate mess, abuse cargo features, and improve compile times. So starting August 8 I want anyone and everyone to periodically remind me to get to work on winapi 0.3.

[retep998]

Also comparing to libc is kinda silly because winapi has an order of magnitude more Rust code, along with only a small subset of libc being compiled for a given platform.
https://api.github.com/repos/rust-lang/libc/languages vs https://api.github.com/repos/retep998/winapi-rs/languages

In terms of pure file size, the files compiled for windows in libc total 23,157 bytes while the files in src for winapi total 2,597,257 bytes.

[retep998]

winapi is now fast to compile.