Fetch version metadata in batches #170
Comments
|
This is effectively blocked on being smarter with ranges for me, either by being a lot faster with intersections, or ideally having ranges with fewer segments. Checking the first ~500 version of tf-models-nightly takes 12s for me, which are nearly exclusively spent on range intersection of ranges with a lot of segments, even though we should be able to merge the segments.
|
|
Is that with all the metadata cached? The fragmented ranges thing is similar to what @zanieb is looking at for error reporting and is related to an issue I filed on PubGrub about this. |
|
Yes, it basically does not make sense to work on this until pubgrub-rs/pubgrub#135 is fixed or we have some workaround. We could try making intersections really fast but i think this would be effort spent in the wrong place when range shouldn't be that large in the first place. |
|
As an update, pubgrub is much faster now, and it will be even faster for this case with pubgrub-rs/pubgrub#177 (the benchmark i used hits the boto case), so we can retry doing this. |
This update pulls in pubgrub-rs/pubgrub#177, optimizing common range operations in pubgrub. Please refer to this PR for a more extensive description and discussion of the changes. The changes optimize that last remaining pathological case, `bio_embeddings[all]` on python 3.12, which has to try 100k versions, from 12s to 3s in the cached case. It should also enable smarter prefetching in batches (#170), even though a naive attempt didn't show better network usage. **before** 12s  **after** 3s  ``` $ taskset -c 0 hyperfine --warmup 1 "../uv/target/profiling/main-uv pip compile ../uv/scripts/requirements/bio_embeddings.in" "../uv/target/profiling/branch-uv pip compile ../uv/scripts/requirements/bio_embeddings.in" Benchmark 1: ../uv/target/profiling/main-uv pip compile ../uv/scripts/requirements/bio_embeddings.in Time (mean ± σ): 12.321 s ± 0.064 s [User: 12.014 s, System: 0.300 s] Range (min … max): 12.224 s … 12.406 s 10 runs Benchmark 2: ../uv/target/profiling/branch-uv pip compile ../uv/scripts/requirements/bio_embeddings.in Time (mean ± σ): 3.109 s ± 0.004 s [User: 2.782 s, System: 0.321 s] Range (min … max): 3.103 s … 3.116 s 10 runs Summary ../uv/target/profiling/branch-uv pip compile ../uv/scripts/requirements/bio_embeddings.in ran 3.96 ± 0.02 times faster than ../uv/target/profiling/main-uv pip compile ../uv/scripts/requirements/bio_embeddings.in ``` It also adds `bio_embeddings[all]` as a requirements test case.
…2452) With pubgrub being fast for complex ranges, we can now compute the next n candidates without taking a performance hit. This speeds up cold cache `urllib3<1.25.4` `boto3` from maybe 40s - 50s to ~2s. See docstrings for details on the heuristics. **Before**  **After**  --- We need two parts of the prefetching, first looking for compatible version and then falling back to flat next versions. After we selected a boto3 version, there is only one compatible botocore version remaining, so when won't find other compatible candidates for prefetching. We see this as a pattern where we only prefetch boto3 (stack bars), but not botocore (sequential requests between the stacked bars).  The risk is that we're completely wrong with the guess and cause a lot of useless network requests. I think this is acceptable since this mechanism only triggers when we're already on the bad path and we should simply have fetched all versions after some seconds (assuming a fast index like pypi). --- It would be even better if the pubgrub state was copy-on-write so we could simulate more progress than we actually have; currently we're guessing what the next version is which could be completely wrong, but i think this is still a valuable heuristic. Fixes #170.
When resolving:
We end up testing hundreds of boto versions. After a point, we should start fetching the version metadata in parallel for these cases.
The text was updated successfully, but these errors were encountered: