[issue37348] Optimize PyUnicode_GetString for short ASCII strings

Inada Naoki added the comment: PR 14291 seems simpler than PR 14283. But PR 14283 is faster because _PyUnicodeWriter is a learge struct. master: 3.7sec PR 14283: 2.9sec PR 14291: 3.45sec compiler: gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0 without LTO, without PGO --

[issue37348] Optimize PyUnicode_GetString for short ASCII strings

Change by Inada Naoki : -- pull_requests: +14114 pull_request: https://github.com/python/cpython/pull/14291 ___ Python tracker ___

[issue37348] Optimize PyUnicode_GetString for short ASCII strings

Inada Naoki added the comment: Another micro benchmark: ``` $ ./python-master -m pyperf timeit -o m1.json 'b=b"foobar"' -- 'b.decode()' . Mean +- std dev: 93.1 ns +- 2.4 ns $ ./python -m pyperf timeit -o m2.json 'b=b"foobar"' -- 'b.decode()' . Mean +-

[issue37348] Optimize PyUnicode_GetString for short ASCII strings

Inada Naoki added the comment: > I don't understand how _PyUnicodeWriter could be slow. It does not > overallocate by default. It's just wrapper to implement efficient memory > management. I misunderstood _PyUnicodeWriter. I thought it caused one more allocation, but it doesn't. But

[issue37348] Optimize PyUnicode_GetString for short ASCII strings

Change by Inada Naoki : -- pull_requests: +14105 pull_request: https://github.com/python/cpython/pull/14283 ___ Python tracker ___

[issue37348] Optimize PyUnicode_GetString for short ASCII strings

STINNER Victor added the comment: > _PyUnicode_FromASCII(s, len) is faster than PyUnicode_FromString(s) because > PyUnicode_FromString() uses temporary _PyUnicodeWriter to support UTF-8. I don't understand how _PyUnicodeWriter could be slow. It does not overallocate by default. It's just

[issue37348] Optimize PyUnicode_GetString for short ASCII strings

Inada Naoki added the comment: Oh, wait. Why we used _PyUnicodeWriter here? Decoding UTF-8 must not require it. 2-pass is enough. -- ___ Python tracker ___

[issue37348] Optimize PyUnicode_GetString for short ASCII strings

Inada Naoki added the comment: > Most of changes are in not performance sensitive code. I do not think there > is a benefit of using new macro there. Because I used just sed. > If PyUnicode_FromString() is slow I prefer to optimize it instead of adding > yet one esoteric private function