-
-
Notifications
You must be signed in to change notification settings - Fork 294
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
pex is inexplicably slow for a small project #1357
Comments
Can you run the equivalent |
There are the results of comparing
vs
I would expect |
Hrm, I find different. My only change was to eliminate some default Pex flags for brevity (
|
That result is consistent for me. After 5 runs of that same hyperfine setup I get I'm on a quiet Linux laptop with ssd and that's the only other set of strongly pertinent variables I can think of. |
@zmanji if you can't repro my results on a quiet machine I'd like to dig more to understand the performance considerations I'm not taking into account. If you can repro my result I'd like to close and let the issues I linked above stand for the case of optimizing pinned resolves / lockfiles. |
On a second mac I can see pip and pex are pretty much equal:
I also thought it was related to this pip issue but deleting the Adding
Feel free to close this. I would suggest pex would be aggressive in adopting |
Some additional data for the record. It seems that adding a With the
After deleting
|
Reported the above to pip disabling pep517 builds makes this a bit more tolerable for me. |
@zmanji that bug report is probably wanting in two ways:
For example, 2 - by design of the PEP - will download the build system (say setuptools) - and then run it. It will not expect the build system to be present in your current interpreters environment. So that hermetic bit of resolving the build system is new and should be expected to take time. |
Hrm, I guess it does - but not in too friendly a way: zmanji/git-squash@e714352 Looks like setuptools / wheel with no bounds. So latest. |
It looks like |
This issue is rambling a bit, but I'll close as agreed upon. |
Hey @jsirois, what's the current status on using |
I've made good progress on the Pip upgrade to latest over in #1805 this week. It looks like Pex will be able to support both the current vendored Pip 20.3.4-patched and be able to download and use Pip 22.2.2 un-patched on the fly behind a flag (currently: |
Actually, Using Pip 22.2.2 and my branch implementing #1805 on @zmanji's test cases I find:
So it's a mixed bag, but Pex is always a bit slower. Pex can come out ahead mixing in |
For the pep517 case could pex ship with a basic wrapper around the It's my understanding the slowest part is building a wheel is creating a clean venv with the dependencies specified in |
It could take on building wheels, but currently it offloads to Pip all it can (Pex currently uses |
The issues to contend with if Pex did tackle wheel building speed optimizations would include what to do about re-use of venvs. There is no way to know just by looking at the top-level |
FWIW the infra does partially exist with an entry point here: That is used when locking local projects to get a consistent hashable thing (build an sdist tarball, then extract it to a dir and hash that dir tree) that represents the relevant project contents and not extraneous bits (.pyc laying about, tool caches like .tox/, etc.) That just supports |
Reproduction
505cf06c598409db9d119a521480e43de3fa8908
pex . -vv -r requirements.txt --no-build --wheel --no-transitive --inherit-path=false --output-file /Users/zmanji/code/git-squash/dist/git-squash-0.0.1.pex --script git-squash -o dist/out.pex
With latest pex on macOS.
Expectation
Because of
--no-build
,--wheel
,--no-transitive
and a fully resolvedrequirements.txt
frompip-compile
building a pex should be very fast. The wheels can be fetched from pypi if they are not cached locally, the package it self a single file, so building the wheel should be very fast and then building the pex should be straight forwardFor reference building the wheel for
git-squash
viapython ./setup.py bdist_wheel
takes about 0.3s on my computer.Reality
I see this output
Notice:
This is very unexpected and there is no information in the output as to why it takes so long. With all of the caching PEX uses, I would expect this to be very fast.
The text was updated successfully, but these errors were encountered: