-
-
Notifications
You must be signed in to change notification settings - Fork 33.2k
gh-125159: Speed up posixpath.realpath()
in the common case
#125158
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
Conversation
posixpath.realpath()
in the common caseposixpath.realpath()
in the common case
cc @barneygale |
Does this make a measurable difference? |
Could you provide the results of the speed test? |
Co-authored-by: Barney Gale <[email protected]>
It's not a lot faster, 2.95 nsec/iteration. |
I think this change isn't worth the churn. |
Just as expected. |
If I understand you correctly, you expected this PR to be rejected. The next time you consider opening a PR that you "expect to be rejected", please consider again the following:
|
@erlend-aasland it's my fault - see #120146 (comment) @nineteendo really sorry for giving you bad advice and wasting your time |
Thanks for being honest, Barney, but it's also my fault. I knew it wasn't a lot faster (much less than the 5% Alex mentioned in the past) and therefore probably wasn't worth a PR to change just that. That doesn't mean that making the code 3 nanoseconds slower for speeding up a rare case is fine though. |
In general, an optimization is worth it if it's at least 10% faster on a microbenchmark. It doesn't seem to be the case here. |
Originally proposed in #120146.
Benchmark
Show script
200 . - no difference
200 .. - 1.02x faster
200 dirs - no difference
posixpath.realpath()
in the common case #125159