Quantify benefit in the readme

[dtolnay]

What is the order of magnitude of the improvement that momo would enable? I think some indication of this would be necessary for readers to determine whether the cost/benefit tradeoff of pursuing momo makes sense.

It would be good to share some numbers from a project that heavily uses generics showing the compile time and binary size measured with and without momo.

[llogiq]

Do you happen to either have or know such a project?

[dtolnay]

No -- which is maybe what drives my skepticism. ;)

[dtolnay]

I tried generating some contrived code that I thought would be a best case scenario for momo -- many large function bodies that are instantiated across multiple generic parameters -- and was not able to find a case where introducing momo would make cargo clean && time cargo build faster. In most of what I tried it ended up compiling slower. I will be curious whether you come up with a different result.

[yvt]

I tried disabling momo in my little personal project (with about 30kLOC and 7 instances of #[momo]) and got the following result:

momo in Cargo.toml	#[momo]	cargo build --release	Executable Size
		474.10s	839.4KB
Yes		501.30s	839.4KB
Yes	Yes	488.40s	825.5KB

momo truly reduces the binary size (which is the primary objective for this project). It also cuts the compilation time down, but the compilation time of momo itself seems to be cancelling it out. I think the slow-down would be more pronounced if there are no other proc-macro crates, and less or virtually non-existent if used in even larger projects.

[llogiq]

I should take the time to convert Momo to Watt.

[jgarvin]

Wouldn't most of the time users have the build of momo cached? I think the time people would mostly care about is missing, where momo is already built but the crate using it is not.