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

[skirpichev]

• Issue: Fractions instantiation revisited #72902

---

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

Details

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

[eendebakpt]

@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]

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]

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]

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]

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

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #32820273 | 📁 Comparing 20436d8 against main (a7d5a6c)

🔍 Preview build

482 files changed · ± 446 modified · - 36 deleted

±Modified

• about.html
• bugs.html
• glossary.html
• index.html
• license.html
• py-modindex.html
• c-api/allocation.html
• c-api/apiabiversion.html
• c-api/arg.html
• c-api/buffer.html
• and 436 more...

-Deleted

• improve-page-nojs.html
• improve-page.html
• _static/tachyon-example-flamegraph.html
• _static/tachyon-example-heatmap.html
• c-api/curses.html
• c-api/extension-modules.html
• c-api/interp-lifecycle.html
• c-api/lifecycle.html
• c-api/picklebuffer.html
• c-api/profiling.html
• and 26 more...