Skip to content

x.py downloads much more than necessary #61667

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

Closed
AaronKutch opened this issue Jun 8, 2019 · 5 comments
Closed

x.py downloads much more than necessary #61667

AaronKutch opened this issue Jun 8, 2019 · 5 comments

Comments

@AaronKutch
Copy link
Contributor

AaronKutch commented Jun 8, 2019

One problem I am having is that running ./x.py test --stage 0 src/libcore is updating several submodules that I assume are not needed at all for just testing src/libcore. For example, it should not need any documentation related submodules, rustfmt, rls, and a bunch of other stuff.

Another problem is that some of these submodules are huge with src/llvm-project taking almost 2 Gigabytes (edit: I estimated wrong, I was reading git object percentage and the actual was 555 MiB) of my precious internet usage. I expect llvm-project to be quite large, but is it trying to download the entire git history? I have to run clones with --depth 1 to make the downloads bearable.

@Mark-Simulacrum
Copy link
Member

We don't have the resources to make patches that optimize for internet usage at this point and largely, x.py doesn't have the knowledge to know whether it needs or doesn't need a submodule. Most of the submodules are small, anyway, aside from llvm.

Since we don't have the resources to change things here I'm going to close this issue. If there are non-invasive patches that can be optionally enabled then we may be able to accept them via PR.

@AaronKutch
Copy link
Contributor Author

So, is the git history needed or can I submit some patch to fix that?

@Mark-Simulacrum
Copy link
Member

On high bandwidth/unmetered networks my understanding is that limiting git history results in slower performance (both for the client and the server); that means that shallow operations are generally non-ideal for us.

@Mark-Simulacrum
Copy link
Member

To be clear -- I think such an option would definitely need to be opt-in, but if it's somewhat non-invasive I'd be willing to consider it.

@AaronKutch
Copy link
Contributor Author

thank you

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

No branches or pull requests

2 participants