Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crate universe isolated makes splicing 4 times slower at least #3212

Open
havasd opened this issue Jan 27, 2025 · 5 comments
Open

Crate universe isolated makes splicing 4 times slower at least #3212

havasd opened this issue Jan 27, 2025 · 5 comments

Comments

@havasd
Copy link
Contributor

havasd commented Jan 27, 2025

After moving to rules_rust 0.57.1 version the splicing of the workspace is at least 4 times slower compared when running with isolated = True. When I set the isolated = False the runtime is comparable to the previous one.

We use from_specs with a pretty large monorepo which contains roughly ~500 external rust dependencies.

EDIT: clarified the issue

@UebelAndre
Copy link
Collaborator

Interesting, I would have expected isolated = False to speed things up as multiple crate_universe modules would be able to share the user's CARGO_HOME. The way crate_universe currently runs in bzlmod is somewhat flawed in that it's bottle-necked by evaluating each module serially. A nice improvement could be to avoid calling cargo-bazel for the repin check, splicing, and generation separately, and instead have the starlark batch all these into a single call to cargo-bazel where cargo-bazel is able to parallelize processing each module. This is something I thought of after migrating //examples/crate_universe to bzlmod which is now incredibly painful to run. Help would be greatly appreciated here!

@havasd
Copy link
Contributor Author

havasd commented Jan 28, 2025

Sorry, my phrasing was bad. When I set isolated = False it is 4 times faster.
To put into context on our repo it runs for 40+ seconds in isolated = True and 10+ seconds with isolated = False

@UebelAndre
Copy link
Collaborator

Yeah, that’s expected. Instead of reusing an already downloaded registry, cargo will download a fresh one which is not super fast.

@havasd
Copy link
Contributor Author

havasd commented Jan 28, 2025

Where did it re-use previously? Did it use the user's cargo cache?

@UebelAndre
Copy link
Collaborator

Yup! Whatever you set as CARGO_HOME or whatever cargo would identify as the default. It’s typically ~/.cargo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants