Thanks to visit codestin.com
Credit goes to github.com

Skip to content

gh-72902: improve Fraction(str) speed (don't use regexp's) #133994

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.

Sign up for GitHub

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

Jump to bottom
Open
wants to merge 9 commits into
base: main
Choose a base branch
from
Open

gh-72902: improve Fraction(str) speed (don't use regexp's) #133994

wants to merge 9 commits into from
+55 −38

Conversation

skirpichev
Copy link
Member

@skirpichev skirpichev commented May 14, 2025 •
edited
Loading

For reviewers. I'm not sure if it worth (code seems more complex, IMO), but speedup for string parsing seems noticeable (1.3-1.5x).

Benchmark ref patch
Fraction('123') 19.4 us 15.3 us: 1.27x faster
Fraction('1/3') 19.7 us 12.6 us: 1.56x faster
Fraction('1.2e-3') 26.5 us 19.9 us: 1.33x faster
Fraction('-.2') 23.6 us 18.1 us: 1.30x faster
Geometric mean (ref) 1.36x faster 
# bench.py
import pyperf
from fractions import Fraction as F

runner = pyperf.Runner()
s = 'Fraction'
for v in ["123", "1/3", "1.2e-3", "-.2"]:
    r = s + '(' + repr(v) + ')'
    runner.bench_func(r, F, v)

@bedevere-app bedevere-app bot mentioned this pull request May 14, 2025
Open
@skirpichev skirpichev marked this pull request as ready for review May 14, 2025 11:01
eendebakpt
eendebakpt reviewed May 14, 2025
View reviewed changes
@eendebakpt

This comment was marked as resolved.

Sign in to view
serhiy-storchaka

This comment was marked as resolved.

Sign in to view

@serhiy-storchaka

This comment was marked as resolved.

Sign in to view
@skirpichev

This comment was marked as resolved.

Sign in to view
@skirpichev skirpichev marked this pull request as draft May 14, 2025 15:10
@skirpichev skirpichev force-pushed the speedup-Fraction-fromstr/72902 branch from 3687e34 to 05e9110 Compare May 16, 2025 03:37
@skirpichev skirpichev marked this pull request as ready for review May 16, 2025 03:53
@skirpichev

This comment was marked as resolved.

Sign in to view
eendebakpt
eendebakpt reviewed May 16, 2025
View reviewed changes
@skirpichev @eendebakpt
Update Lib/fractions.py
7c567fc 
Co-authored-by: Pieter Eendebak <[email protected]>
eendebakpt
eendebakpt approved these changes May 18, 2025
View reviewed changes
Copy link
Contributor

@eendebakpt eendebakpt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@skirpichev Could you also add a test case for Fraction('232e\t2') (this should fail). One optimization I tried passes all the tests, but fails on this one.

Tests pass, and all paths in the new code are needed, so approving. The new code is not very easy to read, but neither is the regular expression that is currently in main.

@skirpichev
Copy link
Member Author

Could you also add a test case for Fraction('232e\t2') (this should fail).

Done.

The new code is not very easy to read, but neither is the regular expression that is currently in main.

I think that the later is more clear. Also, it has more nice tracebacks.

So, I'm still not sure about this. Speed gain is x2 at most. Maybe regexps can be eventually optimized?

@serhiy-storchaka
Copy link
Member

I was surprised that manual parsing is faster than a regexp-based approach. The regular expression is not optimal, so I tried to optimize it, but the benefit was minuscule. The regexp engine needs to be optimized.

Can we please wait a few months with these changes while I try to optimize the regexp engine for such case? This seems so typical that a lot of code would benefit from optimization.

@skirpichev
Copy link
Member Author

I was surprised that manual parsing is faster than a regexp-based approach.

But not too much.

The regexp engine needs to be optimized.
Can we please wait a few months with these changes while I try to optimize the regexp engine for such case?

Sure. I'm not familiar with the regexp module code and I would be interested in such fix, if it's possible at all. BTW, so far this pr was not approved by core dev.

@serhiy-storchaka, but what about other change, i.e. moving down numbers.Rational check? Maybe I should factor out this to a separate pr? See benchmarks (third column) and my arguments for this.

@skirpichev skirpichev marked this pull request as draft May 20, 2025 07:56
@skirpichev
Copy link
Member Author

Ok, now this has only optimization for str inputs. Other goes to #134320

@skirpichev skirpichev marked this pull request as ready for review May 20, 2025 09:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@eendebakpt eendebakpt eendebakpt approved these changes

@serhiy-storchaka serhiy-storchaka Awaiting requested review from serhiy-storchaka

Assignees
No one assigned
Labels
awaiting review
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@skirpichev @eendebakpt @serhiy-storchaka