[issue18685] Restore re performance to pre-PEP393 level

Serhiy Storchaka added the comment: Thank you for your review Antoine and Victor. -- resolution: -> fixed stage: commit review -> committed/rejected status: open -> closed ___ Python tracker __

[issue18685] Restore re performance to pre-PEP393 level

Antoine Pitrou added the comment: I suppose this issue can be fixed then. Thanks for doing this! -- ___ Python tracker ___ ___ Python-

[issue18685] Restore re performance to pre-PEP393 level

Serhiy Storchaka added the comment: Yes, the commit e-mail looks queer. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue18685] Restore re performance to pre-PEP393 level

Antoine Pitrou added the comment: Ah, sorry, no. I was fooled by the commit e-mail. -- ___ Python tracker ___ ___ Python-bugs-list mai

[issue18685] Restore re performance to pre-PEP393 level

Antoine Pitrou added the comment: Didn't you forget to add sre_lib.h? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsu

[issue18685] Restore re performance to pre-PEP393 level

Roundup Robot added the comment: New changeset 00e61cb3b11c by Serhiy Storchaka in branch 'default': Issue #18685: Extract template part of _sre.c into separated sre_lib.h file. http://hg.python.org/cpython/rev/00e61cb3b11c -- ___ Python tracker

[issue18685] Restore re performance to pre-PEP393 level

STINNER Victor added the comment: Sorry, I was busy with my tracemalloc PEP, I didn't havee time to review your patch. I'm happy that you restored Python 3.2 performances! Thanks Serhiy. -- ___ Python tracker

[issue18685] Restore re performance to pre-PEP393 level

Roundup Robot added the comment: New changeset 66e2dfbb1d70 by Serhiy Storchaka in branch 'default': Issue #18685: Restore re performance to pre-PEP 393 levels. http://hg.python.org/cpython/rev/66e2dfbb1d70 -- nosy: +python-dev ___ Python tracker

[issue18685] Restore re performance to pre-PEP393 level

Antoine Pitrou added the comment: Looks good to me. -- stage: patch review -> commit review ___ Python tracker ___ ___ Python-bugs-lis

[issue18685] Restore re performance to pre-PEP393 level

Serhiy Storchaka added the comment: Updated patch addresses Antoine's comments. -- Added file: http://bugs.python.org/file32363/sre_optimize_3.patch ___ Python tracker ___ __

[issue18685] Restore re performance to pre-PEP393 level

Antoine Pitrou added the comment: Posted review on Rietveld. See also issue #19387. -- ___ Python tracker ___ ___ Python-bugs-list mai

[issue18685] Restore re performance to pre-PEP393 level

Serhiy Storchaka added the comment: Please review this patch. I will extract template part into separated file in separated commit. -- ___ Python tracker ___ ___

[issue18685] Restore re performance to pre-PEP393 level

Changes by Serhiy Storchaka : -- dependencies: -Pointers point out of array bound in _sre.c ___ Python tracker ___ ___ Python-bugs-li

[issue18685] Restore re performance to pre-PEP393 level

Serhiy Storchaka added the comment: Rebased patch to tip and added non-ASCII tests for main re functions. -- Added file: http://bugs.python.org/file32283/sre_optimize_2.patch ___ Python tracker

[issue18685] Restore re performance to pre-PEP393 level

Changes by Serhiy Storchaka : -- dependencies: +Fix format specifiers for debug output in _sre.c, Pointers point out of array bound in _sre.c ___ Python tracker ___

[issue18685] Restore re performance to pre-PEP393 level

Changes by Tal Weiss : -- nosy: +Tal.Weiss ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue18685] Restore re performance to pre-PEP393 level

Serhiy Storchaka added the comment: > Using #include "_sre.c" in _sre.c looks weird. Instead of huge sections > delimited by "#ifdef SRE_RECURSIVE", I would prefer something similar to the > stringlib. ".h" template files included more than once. I also expect shorter > files: _sre.c is close

[issue18685] Restore re performance to pre-PEP393 level

STINNER Victor added the comment: Using #include "_sre.c" in _sre.c looks weird. Instead of huge sections delimited by "#ifdef SRE_RECURSIVE", I would prefer something similar to the stringlib. ".h" template files included more than once. I also expect shorter files: _sre.c is close to 4000 li

[issue18685] Restore re performance to pre-PEP393 level

Antoine Pitrou added the comment: Ok, here are some results from the benchmarks suite: Report on Linux fsol 3.8.0-27-generic #40-Ubuntu SMP Tue Jul 9 00:17:05 UTC 2013 x86_64 x86_64 Total CPU cores: 4 ### regex_effbot ### Min: 0.058952 -> 0.054367: 1.08x faster Avg: 0.059060 -> 0.054378: 1.09x

[issue18685] Restore re performance to pre-PEP393 level

Serhiy Storchaka added the comment: I'm under 32-bit Linux with gcc 4.6.3. The above test is only one example for which I expect largest difference. I suppose other tests will show a gain too. -- ___ Python tracker

[issue18685] Restore re performance to pre-PEP393 level

Matthew Barnett added the comment: With the patch the results are: C:\Python34\python.exe -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*10" "f(x)" 1 loops, best of 3: 113 usec per loop C:\Python34\python.exe -m timeit -s "import re; f = re.compile('abc').search; x

[issue18685] Restore re performance to pre-PEP393 level

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue18685] Restore re performance to pre-PEP393 level

Antoine Pitrou added the comment: > @Antoine: Are you on the same OS as Serhiy? I don't know, I'm under Linux with gcc (on a x86-64 machine) :-) > IIRC, wasn't the performance regression that wxjmfauth complained > about in Python 3.3 apparent on Windows, but not on Linux? I don't know, but I'

[issue18685] Restore re performance to pre-PEP393 level

Matthew Barnett added the comment: @Antoine: Are you on the same OS as Serhiy? IIRC, wasn't the performance regression that wxjmfauth complained about in Python 3.3 apparent on Windows, but not on Linux? -- ___ Python tracker

[issue18685] Restore re performance to pre-PEP393 level

Antoine Pitrou added the comment: I get the same kind of results as Serhiy: $ python3.2 -m timeit -s "import re; f = re.compile(b'abc').search; x = b'x'*10" "f(x)" 1 loops, best of 3: 81.7 usec per loop $ python3.2 -m timeit -s "import re; f = re.compile('abc').search; x = 'x'*10"

[issue18685] Restore re performance to pre-PEP393 level

Changes by Antoine Pitrou : -- nosy: +tim_one ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue18685] Restore re performance to pre-PEP393 level

Matthew Barnett added the comment: It appears that in your tests Python 3.2 is faster with Unicode than bytestrings and that unpatched Python 3.4 is a lot slower. I get somewhat different results (Windows XP Pro, 32-bit): C:\Python32\python.exe -m timeit -s "import re; f = re.compile(b'abc').s

[issue18685] Restore re performance to pre-PEP393 level

New submission from Serhiy Storchaka: Before PEP 393 the regex functions scanned an array of char or Py_UNICODE and character testing was cheap. After PEP 393 they checks a kind of an unicode string for every tested character and processing of unicode strings becomes slower. _sre.c already gen