| msg177997 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) *  |
Date: 2012-12-23 16:50 |
| The proposed patch optimizes _PyUnicode_FindMaxChar(). This affects string formatting of long patterns (speedup to 15-25% for classic formatting and 5-8% for new style formatting). |
|
|
| msg178066 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2012-12-24 15:59 |
| See issues #14687 and #14716 for benchmarks and information about the changes introducing and using _PyUnicodeWriter for str%args and str.format(args). |
|
|
| msg178067 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2012-12-24 16:03 |
| Avoid scanning a substring to compute the maximum character is a good thing, so +1 for the idea. Instead of modifying an existing function, it might be safer to rename it. Even if it is private, a third party module *can* use it outside Python. It is also surprising that you have to specifiy a "maxchar" argument whereas the purpose of the function is to compute the maximum character. Ex: rename _PyUnicode_FindMaxChar() to _PyUnicode_FindMaxChar2(), and add _PyUnicode_FindMaxChar() as the macro: #define _PyUnicode_FindMaxChar(str, start, length) _PyUnicode_FindMaxChar2(str, start, length, 127) |
|
|
| msg178076 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2012-12-24 16:48 |
| It is not more surprising that specify a "start" argument for sum(). I don't think we should worry about third party module which violate the API. It will crash in any case when the exported function will disappear and will be replaced by macros. |
|
|
| msg178081 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2012-12-24 17:45 |
| > It is not more surprising that specify a "start" argument for sum(). Un pythin, the start attribute of sum is optional. > I don't think we should worry about third party module which violate the API. It will crash in any case when the exported function will disappear and will be replaced by macros. The compilation will fail, whereas it will crash with your patch. |
|
|
| msg178099 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2012-12-24 20:53 |
| I think it is redundant and useless, but do as you want. |
|
|
| msg185866 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2013-04-03 00:02 |
| Related commit: changeset: 83066:b5d5f422299f tag: tip user: Victor Stinner <victor.stinner@gmail.com> date: Wed Apr 03 01:48:39 2013 +0200 files: Include/unicodeobject.h Lib/test/test_format.py Objects/stringlib/unicode_format.h Objects/unicodeobject.c description: Add _PyUnicodeWriter_WriteSubstring() function Write a function to enable more optimizations: * If the substring is the whole string and overallocation is disabled, just keep a reference to the string, don't copy characters * Avoid a call to the expensive _PyUnicode_FindMaxChar() function when possible |
|
|
| msg185867 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2013-04-03 00:03 |
| New changeset 7132bca093ad by Victor Stinner in branch 'default': Close #16757: Avoid calling the expensive _PyUnicode_FindMaxChar() function http://hg.python.org/cpython/rev/7132bca093ad |
|
|
| msg185868 - (view) |
Author: STINNER Victor (vstinner) * |
Date: 2013-04-03 00:06 |
| > New changeset 7132bca093ad by Victor Stinner in branch 'default': > Close #16757: Avoid calling the expensive _PyUnicode_FindMaxChar() function This changeset is almost the same than unicode_findmaxchar_2.patch. I prefered to keep the API unchanged and not call _PyUnicode_FindMaxChar() instead of adding a test in the function to exit it. There is just a minor difference in Python/formatter_unicode.c: the test for _PyUnicode_FindMaxChar() is done after the test on format->fill_char (which should avoid a call to for _PyUnicode_FindMaxChar() if fill_char is wider than the actual buffer). Thanks Serhiy for your great idea! |
|
|