Repository navigation
Clippy linting is very slow #528
Description
I switched to using clippy for linting GPU code in CI and I think it increased CI time by ~8 minutes.
I don't think it should take 8 minutes to run cargo clippy though.
Here is CI run where build.rs for GPU crate was skipping all the work under Clippy: https://github.com/nazar-pc/abundance/actions/runs/21787689837/job/62861720690#step:11:1022
Here is CI run where SpirvBuilder::clippy() is called: https://github.com/nazar-pc/abundance/actions/runs/21905750349/job/63245490660#step:11:1023
Clippy time for ab-farmer crate that includes ab-proof-of-space-gpu as a dependency increased from ~2 minutes to over 10 minutes.
Dependencies for SPIR-V are fairly minimal too and should not take nearly as much time to compile and lint: https://github.com/nazar-pc/abundance/blob/c55eae7482783aea52f0f1e9510e71378c9f10b8/crates/farmer/ab-proof-of-space-gpu/Cargo.toml#L19-L23
I do not know what could it possibly be doing for such a long time, but I do not like it.
Activity
Firestar99 commentedon Feb 12, 2026
Important Note: You have a quite custom build script. Don't run
cargo gpu clippyor anything like this, instead, the build script will delegatecargo clippyto also run clippy with rust-gpu, and otherwise build with rust-gpu like normal.rustc_codegen_spirvab-proof-of-space-gpu:ab-farmer:libtool, docs appreciated :Dhwlocality-sys, not rust-gpu!ab-farmerwith older Rust-GPU/cargo-gpu@7016069 before 2 PRsab-farmeron commit nazar-pc/abundance@87fe6a8TLDR: not really able to figure out what's wrong on my local machine
nazar-pc commentedon Feb 12, 2026
At least on Windows there is certainly a massive difference.
To demonstrate I made a simple change on top of
main: nazar-pc/abundance@93cdea0This is the latest
mainbranch wherewindows-2025 individuallyjob takes 20m 59s to complete: https://github.com/nazar-pc/abundance/actions/runs/21930624164This is another run with above commit on top where
windows-2025 individuallyjob takes 9m 51s: https://github.com/nazar-pc/abundance/actions/runs/21946267916There is literally a single line change that either calls
SpirvBuilder::clippy()or doesn't.P.S. As for hwlocality - it is awesome, but hwloc C dependency takes a while to compile indeed with extra environment dependencies. I hope to replace it with pure Rust https://github.com/WildPixelGames/gdt-cpus once it matures with more features. But either way my concern is only about rust-gpu causing CI delays on top of whatever baseline is.
nazar-pc commentedon Feb 12, 2026
I guess downloading/installing of the custom toolchain is another difference on top of running clippy as such. And Windows seems to be particularly horrible with the file system operations, but it still doesn't take quite as long to install the toolchain of the workspace itself.
Firestar99 commentedon Feb 12, 2026
Are you comparing running clippy with rust-gpu toolchain vs
A) not running anything or
B) running cargo check with rust-gpu?
Cause I've been testing for B, but your latest comment sounds like you're testing for A.
Also are you caching
~/.cache/rust-gpu/codegen/*/*.so, so the codegen backend doesn't need to be rebuild every time?nazar-pc commentedon Feb 12, 2026
I'm always calling
cargo clippywith the up to date nightly toolchain. Internally insidebuild.rsit either callsSpirvBuilder::clippy()or it doesn't. I never callSpirvBuilder::check()because it is not distinguishable from regular build insidebuild.rsto the best of my knowledge.The only things cached in CI are
~/.cargo/registryand~/.cargo/git.Firestar99 commentedon Feb 12, 2026
Sidenote: I've just released spirv-tools 0.13.1 which may affect future measurements
Firestar99 commentedon Feb 12, 2026
In commit nazar-pc/abundance@54bff2f you're (effectively) doing
cargo gpu checkin your build script and CI times have already worsened to 20minMeaning this is not a clippy specific problem. The problem is that you're now building and using rust-gpu in your clippy job, which is making it take ~10min a lot longer. cargo-gpu CI also takes 10min to run on github provided runners, so I'd call this very much expected.
nazar-pc commentedon Feb 14, 2026
Interesting. Why does it need to take a whopping 10 minutes to build though? Is it compiling a huge amount of code with crazy optimizations or something?
I guess I can try caching the codegen backend so it is not rebuilt every time, but at the same time 10 minutes is a reeeally long time.
Firestar99 commentedon Feb 15, 2026
When I do a local build on my old Notebook,
spirv-toolsC++ compile alone takes ~2min and all of rust only takes 1min. Which is why I started to question whether we actually needspirv-tools, sincespirv-optisn't that great andspirv-valis in theory optional. And what is driving #521nazar-pc commentedon Feb 16, 2026
Would it be possible to skip building C++ stuff when only clippy is called? There would be no SPIR-V produced in that case anyway.
Firestar99 commentedon Feb 16, 2026
Well we used to have such an optimization... and I just patched it out:
Comment on that issue:
I was throwing out the idea of having spirv-tools be feature gated, but that would also require cargo-gpu support for codegen backends with various features. Currently, it just builds all codegens with default features. But even if you have separate features, you'd be forcing everyone who already has a codegen backend with spirv-tools to compile it again without spirv-tools. And we can't coerce the two builds, since spirv-opt affects build output significantly.
nazar-pc commentedon Feb 16, 2026
Isn't spirv-opt a CLI program? If so then it should be possible to compile it optionally, while the codegen backend has its support built-in. If it is compiled as a library then it is a bit of a problem though.
Firestar99 commentedon Feb 16, 2026
True, and
spirv-toolsdoes have the two featuresuse-compiled-toolsanduse-installed-tools, which we make use of in rust-gpu CI. The main problem is that cargo-gpu does not support forwarding features to the codegen backend, and may need a new caching strategy to support that. For now we've decided to hardcode the default features (aka.use-compiled-tools), which also got rid of issues where people used newer spirv tools that introduced some new validation, suddenly making their compiles fail.