re is much slower than cpython
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.6k
- Forks
- 155
- Avg merge
- 9h 42m
- Merged PRs (30d)
- 36
Description
I've been adding graal support to a classifier type project naively based on applying a bunch of regexes to an input, and while Graal works the regex application is quite slow: it's about 4x slower than cpython, while using 4 times the CPU.
Here's a repro script and attending data (basically a cut down version of the naive classifier implementation): script.zip
timings:
> python3.12 --version
Python 3.12.6
> time python3.12 run.py
75158 lines in 11.7s
156.1 us/line
python3.12 run.py 11.77s user 0.05s system 97% cpu 12.172 total
> graalpy --version
GraalPy 3.11.7 (Oracle GraalVM Native 24.1.0)
> time graalpy run.py
75158 lines in 48.2s
640.7 us/line
graalpy run.py 192.00s user 1.00s system 394% cpu 48.976 total
This is on a 10-core M1 Pro. Using cpusampler I confirmed that essentially all the "user" time is in _sre:
_search || 43580ms 98.6% || 43580ms 98.6% || <frozen graalpy._sre>~1:0
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by running the attached script.zip reproduction and comparing the Python 3.12 and GraalPy timings. Inspect the _sre _search hotspot identified by cpusampler and the run.py entry point. Done means the regex workload no longer shows the reported slowdown and the reproduction timings document the improvement.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100