-
Notifications
You must be signed in to change notification settings - Fork 615
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
50ms overhead between resolution time and wall time in uv lock
#4860
Comments
The gap I see here is also present in tracing. Like the last tracing message clocks in at |
Is it possible the branch you're testing on doesn't have: #4793 |
I'm seeing this with a release build from d787e69. With your numbers i get 0.163996s - 143ms = 21ms unaccounted between start and start of resolution and 0.205s - 143ms = 62ms in total, so this seems to be happening on mac too? |
@ibraheemdev - do you have any idea where that time could be going? |
kinda got curious so dug around a bit - seems like uv/crates/uv-requirements/src/upgrade.rs Line 76 in ffcc052
|
That’s interesting… we should profile it. |
I think it's the same problem, but
|
It looks like there's ~20-30ms of overhead before starting resolution in |
## Summary Avoid serializing and writing the lockfile if a cheap comparison shows that the contents have not changed. ## Test Plan Shaves ~10ms off of #4860 for me. ``` ➜ transformers hyperfine "../../uv/target/profiling/uv lock" "../../uv/target/profiling/baseline lock" --warmup 3 Benchmark 1: ../../uv/target/profiling/uv lock Time (mean ± σ): 130.5 ms ± 2.5 ms [User: 130.3 ms, System: 85.0 ms] Range (min … max): 126.8 ms … 136.9 ms 23 runs Benchmark 2: ../../uv/target/profiling/baseline lock Time (mean ± σ): 140.5 ms ± 5.0 ms [User: 142.8 ms, System: 85.5 ms] Range (min … max): 133.2 ms … 153.3 ms 21 runs Summary ../../uv/target/profiling/uv lock ran 1.08 ± 0.04 times faster than ../../uv/target/profiling/baseline lock ```
## Summary We currently store wheel URLs in an unparsed state because we don't have a stable parsed representation to use with rykv. Unfortunately this means we end up reparsing unnecessarily in a lot of places, especially when constructing a `Lock`. This PR adds a `UrlString` type that lets us avoid reparsing without losing the validity of the `Url`. ## Test Plan Shaves off another ~10 ms from #4860. ``` ➜ transformers hyperfine "../../uv/target/profiling/uv lock" "../../uv/target/profiling/baseline lock" --warmup 3 Benchmark 1: ../../uv/target/profiling/uv lock Time (mean ± σ): 120.9 ms ± 2.5 ms [User: 126.0 ms, System: 80.6 ms] Range (min … max): 116.8 ms … 125.7 ms 23 runs Benchmark 2: ../../uv/target/profiling/baseline lock Time (mean ± σ): 129.9 ms ± 4.2 ms [User: 127.1 ms, System: 86.1 ms] Range (min … max): 123.4 ms … 141.2 ms 23 runs Summary ../../uv/target/profiling/uv lock ran 1.07 ± 0.04 times faster than ../../uv/target/profiling/baseline lock ```
#5235 cut the time by another ~13%:
|
Might be worth profiling this again at some point. |
When running
uv lock
on https://github.com/konstin/transformers/blob/9638c4defb18f5358c70f40dd00d65595657dd57/pyproject.toml, i get:with values in the 60ms-70ms range. But when measuring wall time, i get:
That's an ~50ms overhead!
With #4495 applies, the resolution is down to 12ms, but wall time is 60ms, still roughly a 50ms overhead. We should investigate and fix what's slowing us down here.
The text was updated successfully, but these errors were encountered: