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

Performance Tracking: generate-lockfiles #21223

Open
sureshjoshi opened this issue Jul 28, 2024 · 6 comments
Open

Performance Tracking: generate-lockfiles #21223

sureshjoshi opened this issue Jul 28, 2024 · 6 comments

Comments

@sureshjoshi
Copy link
Member

There is a common mention/complaint that calling pants generate-lockfiles :: is slow. Creating this ticket to capture associated discussions, tickets, and even better, sample repos.

From my brief experiments, using pip 24.1 improves cold lockfile generation by about 50% on a small set of requirements, but does not affect incremental checking.

Some ideas that have been floated around:

@jsirois
Copy link
Contributor

jsirois commented Jul 28, 2024

Use pex's incremental lockfile updates (available, but not wired into Pants)

This is widely misunderstood. Pex does incremental updates of lock files, but it does this using a full Pip resolve which is exactly as fast as a normal lock create. This bug tracks doing an incremental resolve: pex-tool/pex#2044 These are two orthogonal things.

Use fast-deps if we're not currently doing so

See here, but I tried this and found its still slow: pex-tool/pex#2375 (comment)

@sureshjoshi
Copy link
Member Author

This, bug tracks doing an incremental resolve: pex-tool/pex#2044 These are two orthogonal things.

I was just writing a comment on that ticket asking whether what we have today vs what the ticket refers to were comparable. So "incremental update" vs "incremental resolve" would be a better distinction on the pex side.

See here, but I tried this and found its still slow: pex-tool/pex#2375 (comment)

Ah, that sucks, but yeah - that was just an example I grabbed from one of the many slack/discussions/issues about this.

@cburroughs
Copy link
Contributor

Tracker of several pending pip performance improvements: pypa/pip#12184

@cburroughs
Copy link
Contributor

Sorry, the correct tracker is now: pypa/pip#12921

cburroughs added a commit to cburroughs/pants that referenced this issue Sep 12, 2024
The first version of pip to support Python 3.13 was 24.1, but I don't
think there is any merit to holding back when 24.2 is already
out. (Pants itself uses `latest`.) The first version of Pex to
support 24.2 is v2.13.0.

(Pip 24.1 and 24.2 also both contain meaningful performance
improvements to dependency resolution --> pantsbuild#21223)

Release notes for where pex added support:
https://github.com/pex-tool/pex/releases/tag/v2.13.0

ref pantsbuild#20852
cburroughs added a commit that referenced this issue Sep 16, 2024
The first version of pip to support Python 3.13 was 24.1, but I don't
think there is any merit to holding back when 24.2 is already out.
(Pants itself uses `latest`.) The first version of Pex to support 24.2
is v2.13.0.

(Pip 24.1 and 24.2 also both contain meaningful performance improvements
to dependency resolution --> #21223)

Release notes for where pex added support:
https://github.com/pex-tool/pex/releases/tag/v2.13.0

ref #20852
@cburroughs
Copy link
Contributor

@notatallshaw
Copy link

It would be very helpful if you can report resolutions that are slow or problamatic on either https://github.com/notatallshaw/Pip-Resolution-Scenarios-and-Benchmarks or https://github.com/pypa/pip.

Probably you would be best switching to uv (which I do also report lots of resolution issues to), but I do aim to keep improving pip's resolver.

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

4 participants