-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Use structured wheel tags everywhere #10542
Conversation
f667ff2
to
e886b46
Compare
3f6768c
to
15465eb
Compare
e886b46
to
17241c3
Compare
17241c3
to
7c0e8d6
Compare
7c0e8d6
to
77e0518
Compare
CodSpeed Performance ReportMerging #10542 will degrade performances by 36.27%Comparing Summary
Benchmarks breakdown
|
77e0518
to
9c1f456
Compare
Hmm... I wonder if the |
15465eb
to
bf3e93d
Compare
9c1f456
to
fb469b5
Compare
fb469b5
to
0b20bb3
Compare
5da08b0
to
9bfe1b7
Compare
a433af2
to
60f6eaa
Compare
60f6eaa
to
6b4b12d
Compare
@@ -912,6 +1047,7 @@ mod tests { | |||
Arch::X86_64, | |||
)) | |||
.unwrap(); | |||
let tags = tags.iter().map(ToString::to_string).collect::<Vec<_>>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No changes here which is really nice. Confirms that the tag generation and formatting remains unchanged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
The regressions on wheelname parsing are interesting, but it looks like the higher level benchmarks point to an improvement?
Yeah. I need to run them locally. We are doing a bit more work, but we’re also not allocating anymore… |
implementation: "GraalPy", | ||
tag: s.to_string(), | ||
})?; | ||
let rest = &rest[..version_end]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can use split_once to avoid the manual indexing which can panic
/// Ex) `manylinux2010_x86_64` | ||
Manylinux2010 { arch: Arch }, | ||
/// Ex) `manylinux2014_x86_64` | ||
Manylinux2014 { arch: Arch }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
depending on whether we care about preserving those verbatim, we can translate the manylinux tags to their modern representation through their associated glibc version (mapping at https://peps.python.org/pep-0600/#legacy-manylinux-tags)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's important to preserve them verbatim.
} | ||
})?; | ||
|
||
let second_underscore = memchr::memchr(b'_', &rest.as_bytes()[first_underscore + 1..]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is perf bottleneck, rather than memchr, i'd use our knowledge that the first number can only be a 2
, so the second underscore must be two bytes after the first, given that it is in bounds and that there is an underscore at this position (when byte indexed, to not panic)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this true, though? Like, in theory, we could start returning numbers that aren't 2
from the get_interpreter_info.py
.
} | ||
})?; | ||
|
||
let second_underscore = memchr::memchr(b'_', &rest.as_bytes()[first_underscore + 1..]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as for manylinux here, except the major is 1
} | ||
|
||
#[derive(Debug, thiserror::Error, PartialEq, Eq)] | ||
pub enum ParsePlatformTagError { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An option to trim down the error handling boilerplate a bit is moving the shared tag outside, similar to:
#[error("{kind}, platform tag: {tag}")]
struct ParsePlatformTagError {
tag: String,
kind: ParsePlatformTagErrorKind,
}
enum ParsePlatformTagErrorKind {
#[error("Invalid format for {platform}")]
InvalidFormat { platform: &'static str },
// ...
}
I don't think the CodSpeed regressions are "real". On main:
On this branch:
After the #10546 PR:
So the short tag case is about 30% faster, and the long tag case is either unchanged or 15% faster. |
(My guess is that we're doing more CPU work than before (due to the parsing) but no longer allocating.) |
Checking with hyperfine, there is a speedup
and the speedup is significant (welch t-test, t = 8.12, p = 6.55e-14). |
a986bf8
to
f1115d0
Compare
230e5ac
to
96e76a8
Compare
96e76a8
to
edde6a3
Compare
edde6a3
to
c306d12
Compare
c306d12
to
1320c7b
Compare
Summary
This PR extends the thinking in #10525 to platform tags, and then uses the structured tag enums everywhere, rather than passing around strings. I think this is a big improvement! It means we're no longer doing ad hoc tag parsing all over the place.