search

rust-lang / rust-clippy

A bunch of lints to catch common mistakes and improve your Rust code. Book: https://doc.rust-lang.org/clippy/
https://rust-lang.github.io/rust-clippy/
Other
11.25k stars 1.52k forks source link

PGO applicability #10121

Open zamazan4ik opened 1 year ago

zamazan4ik commented 1 year ago

Description

Since the Rust compiler uses PGO (and even BOLT on some platforms) I am wondering - could we use the same approach for the Clippy? It also could improve user experience, since Clippy is repeatedly running on local dev machines and CI farms.

@kobzol I guess you could provide more information here since you are a PGO Jedi in the Rust ecosystem :)

I guess the main problem here could be getting a good profile. Here we can run e.g. all clippy checks on a subset of "sample" crates and use these profiles during PGO/Bolt optimization.

Version

Latest

Additional Labels

No response

matthiaskrgr commented 1 year ago

I don't think this will work/be worth it. Rustc is already getting optimized and clippy uses the rustc_driver lib which is already optimized by itself I think? Trying to optimize clippy itself like this might require to statically link everything into clippy which would probably 30x the build time with marginal (3-7%?) speedups?

zamazan4ik commented 1 year ago

Trying to optimize clippy itself like this might require to statically link everything into clippy which would probably 30x the build time with marginal (3-7%?) speedups

Well, actually I think for some kind of "release" builds (which are shipped to the users) 3-7% speed up is definitely worth it (if we really could get it with PGO), even with 30x build time price since this "release" build will be triggered really rarely, and clippy user base is huge.

I didn't test how much we could get with PGO for clippy since I do not know, how to use locally-built cargo-clippy with cargo itself.

Kobzol commented 1 year ago

Interesting suggestion. I have thought about it before (PGO all the things - rustdoc, clippy, rustfmt etc.). But as @matthiaskrgr has already mentioned, I'm not sure if it's worth it.

Tools like clippy already use librustc_driver, which is in fact PGO optimized, so I guess that most of the gains are already "priced in". Adding a PGO build pipeline is highly non-trivial, complicates the deployment process and also makes CI slower, which is already an annoying problem for rustc. I would be surprised if PGO would help for clippy a lot, but even if it had < 10 % gains, I don't think that it would be worth the added maintenance cost. I haven't seen clippy being mentioned as a bottleneck, but even then PGO would probably not be a silver bullet to fix that.

An additional problem that you have already mentioned, is that we don't have a benchmark suite for clippy and we don't run any benchmarks for it. So even if we applied PGO, it would not be measurable regularly. We could of course add some clippy benchmarks to rustc-perf, but the suite is already quite complex (and is currently undergoing a large change - runtime benchmarks) and I'm hesitant to complicate it further for clippy.

I'll try to see how we could apply PGO to clippy and perform some local measurements, but I'm quite skeptical.

Btw the "release" build is actually triggered very often, since we typically don't distinguish from "normal (merge/dist)" and "release" builds, which makes things simpler to maintain and test.