-
Notifications
You must be signed in to change notification settings - Fork 738
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
Python interpreter download is a bottleneck #6212
Comments
Oo that sounds cool. |
Though wouldn't people have the |
The docker is more for illustration purposes, i'm thinking about any uncached deployment enviroment where you also want to install python, but also the first run on a new machine experience of uv. |
For docker specifically, i'd recommend, in order:
|
🤞 #6053 |
When performing an uncached install, the majority of the time is spent on waiting for python to download and unpack. This download is a bottleneck, because nothing else happens in parallel. We should parallelize the python download to run in parallel with package downloads and unpacks, while stalling package builds. We have to add the interpreter info for each interpreter we can download to uv (or make it available online) so we start evaluating wheel tags without having a physical interpreter.
Reproducer:
pyproject.toml
uv.lock
uv python install 3.12
takes 2.5s on my machine, anduv sync
takes 1.5s, while onlyuv sync
takes 4s. On a shared server i tried, i get 6.5s for python and 3.5s for the sync. While both use network, disk and io, they are still much faster running in parallel, just like parallel download and unpack for wheels is much faster than sequential wheel install.The text was updated successfully, but these errors were encountered: