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

Speed up pyc compilation #2637

Open
hauntsaninja opened this issue Mar 24, 2024 · 4 comments
Open

Speed up pyc compilation #2637

hauntsaninja opened this issue Mar 24, 2024 · 4 comments
Labels
performance Potential performance improvement

Comments

@hauntsaninja
Copy link
Contributor

hauntsaninja commented Mar 24, 2024

Thanks for implementing #1788 , it's been great!

Since currently pyc compilation is implemented as a pass over the entire env, it can be quite costly:

λ uv pip install pypyp --compile 
Resolved 1 package in 123ms
Downloaded 1 package in 68ms
Installed 1 package in 28ms
Bytecode compiled 58064 files in 53.81s
 + pypyp==1.2.0

In this venv, it's about 1000x longer than it takes to install without pyc compilation.

Note this very slow time is on macOS, it's much better on Linux machines I have access to (more like 10s). See #2326 (comment) for my laptop specs

To be clear, this is not a particularly pressing issue. The need to bytecode compile deltas is much lower than when building things from scratch. Nevertheless, ideally uv should be significantly faster than pip in all usage scenarios.

With that in mind, some possible suggestions:

  1. It looks like uv currently forces recompilation

    path, invalidation_mode=invalidation_mode, force=True, quiet=2

    I'm not sure why this is... maybe something to do with checked hash validation that compileall doesn't handle correctly? The script predates Add an option to bytecode compile during installation #2086 , so maybe there's something else going on
    (update: I've merged this change)

  2. We could only bytecode compile the newly installed packages

  3. If uv no longer forces recompilation, you could move the invalidation / mtime logic into Rust, not sure how much that would help, but could conceivably save you from shelling to compileall

  4. Something something copy on write for pyc

@hauntsaninja
Copy link
Contributor Author

It looks like pip forces recompilation too, and this goes back to pip v1.5 pypa/pip@7ec49dc#diff-9b28941fa609b0277432cba3444d4595da4ef80ca7c04e9024c75bb0a15ae830R163

Couldn't discern a reason for that, but since it's only doing it for the newly installed package I guess it doesn't hurt much

@AlexWaygood AlexWaygood added the performance Potential performance improvement label Mar 24, 2024
@charliermarsh
Copy link
Member

Makes sense! I assume the highest-impact thing here would be to only recompile newly-installed packages.

@hauntsaninja
Copy link
Contributor Author

Yeah, probably. I just tested my first suggestion since it's easy:

diff --git a/crates/uv-installer/src/pip_compileall.py b/crates/uv-installer/src/pip_compileall.py
index 47e0242f..20bb3c6e 100644
--- a/crates/uv-installer/src/pip_compileall.py
+++ b/crates/uv-installer/src/pip_compileall.py
@@ -47,7 +47,7 @@ with warnings.catch_warnings():
         # We'd like to show those errors, but given that pip thinks that's totally fine,
         # we can't really change that.
         success = compileall.compile_file(
-            path, invalidation_mode=invalidation_mode, force=True, quiet=2
+            path, invalidation_mode=invalidation_mode, force=False, quiet=2
         )
         # We're ready for the next file.
         print(path)

And it speeds things up 2-3x, in the above case from 55s to 20s. Would probably stack well with the third suggestion too, in case we like compiling the whole venv (if it's fast no reason not to)

@charliermarsh
Copy link
Member

I'm cool with shipping that.

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

No branches or pull requests

3 participants