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.
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
Use _PyUnicodeWriter API in text decoders #60515
Comments
Attached patch modifies text decoders to use the _PyUnicodeWriter API to factorize the code. It removes unicode_widen() and unicode_putchar() functions.
I wrote the patch to factorize the code, but it might be faster. |
"Soon I'll post a patch, which speeds up unicode-escape and raw-unicode-escape decoders to 1.5-3x. Also there are not yet reviewed patches for UTF-32 (bpo-14625) and charmap (bpo-14850) decoders. Will be merge conflicts." codecs_writer.patch doesn't change too much the core of decoders, but mostly the code before and after the loop, and error handling. You can still use PyUnicode_WRITE, PyUnicode_READ, memcpy(), etc. "But I will review the patch." If you review the patch, please check that how the buffer is allocated. It should not be overallocated by default, only on the first error. Overallocation can kill performances when it is not necessary (especially on Windows). |
I will do some experiments and review tomorrow. |
I updated the patch to resolve the conflict with bpo-14625. |
With the patch UTF-8 decoder 20% slower for some data. UTF-16 decoder 20% faster for some data and 20% slower for other data. UTF-32 decoder slower for many data (even after some optimization, naive code was up to 50% slower). Standard charmap decoder 10% slower. Only UTF-7, unicode-escape and raw-unicode-escape have become much faster (unicode-escape and raw-unicode-escape as with bpo-16334 patch). A well optimized decoders do not benefit from the _PyUnicodeWriter, only a slight slowdown. The patch requires some optimization (as for UTF-32 decoder) to reduce the negative effect. Non-optimized decoders will receive the great benefit. |
I ran decodebench.py and bench-diff.py scripts from bpo-14624, I just Using _PyUnicodeWriter should not change anything to performances on |
New changeset 7ed9993d53b4 by Victor Stinner in branch 'default': |
Oh, I forgot my benchmark results. decodebench.py result results on Linux 32 bits: $ ./python bench-diff.py original writer
ascii 'A'*10000 4109 (-3%) 3974 latin1 'A'*10000 3851 (-5%) 3644 utf-8 'A'*10000 3747 (-4%) 3608 utf-16le 'A'*10000 4154 (-1%) 4117 utf-16be 'A'*10000 3218 (-1%) 3185 utf-32le 'A'*10000 1681 (+12%) 1885 utf-32be 'A'*10000 1685 (+11%) 1868 decodebench.py result results on Linux 64 bits: ascii 'A'*10000 10043 (+1%) 10144 latin1 'A'*10000 8351 (-1%) 8258 utf-8 'A'*10000 8083 (+5%) 8461 utf-16le 'A'*10000 5547 (-2%) 5422 utf-16be 'A'*10000 5416 (-5%) 5157 utf-32le 'A'*10000 1743 (+8%) 1880 utf-32be 'A'*10000 1761 (+6%) 1860 Most significant changes:
@serhiy Storchaka: If you feel able to tune _PyUnicodeWriter to I consider the performance changes acceptable and I don't plan to work |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: