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
Avoid temporary Unicode strings, use identifiers to only create the string once #63711
Comments
In interactive mode, when I run python in gdb, I see that PyUnicode_DecodeUTF8Stateful() is called a lot of times. Calls come from PyDict_GetItemString() or PySys_GetObject() for example. Allocating a temporary Unicode string and decode a byte string from UTF-8 is inefficient: the memory allocator is stressed and the byte string is decoded at each call. I propose to reuse the _Py_IDENTIFIER API in most common places to limit calls to the memory allocator and to PyUnicode_DecodeUTF8Stateful(). |
pysys_getobjectid.patch:
|
PySys_GetObject() is called with followed literal strings: argv, displayhook, excepthook, modules, path, path_hooks, path_importer_cache, ps1, ps2, stderr, stdin, stdout, tracebacklimit. PyDict_GetItemString() is called with followed literal strings: __abstractmethods__, __builtins__, __file__, __loader__, __module__, __name__, __warningregistry__, _abstract_, _argtypes_, _errcheck_, _fields_, _flags_, _iterdump, _needs_com_addref_, _restype_, _type_, builtins, decimal_point, default_int_handler, displayhook, excepthook, fillvalue, grouping, imp, metaclass, options, sys, thousands_sep. Are any of these calls performance critical? |
I'm trying to focus on the interactive interpreter. I didn't touch literal strings used once, for example at module initialization. Well, if it doesn't make the code much uglier or much slower, it's maybe not a big deal to replace all string literals with identifiers. |
New changeset a2f42d57b91d by Victor Stinner in branch 'default': New changeset 55517661a053 by Victor Stinner in branch 'default': New changeset af822a6c9faf by Victor Stinner in branch 'default': |
Oh, by the way, identifiers have a nice side effect: they are interned, and so dict lookup should be faster. |
New changeset 8a6a920d8eae by Victor Stinner in branch 'default': New changeset 69071054b42f by Victor Stinner in branch 'default': New changeset 862a62e61553 by Victor Stinner in branch 'default': New changeset e5476ecb8b57 by Victor Stinner in branch 'default': |
I don't think these changes are required. The interactive interpreter is not a bottleneck. And definitely adding new public functions to API needs more discussion. |
What is the problem with these changes? Identifiers have different advantages. Errors become more unlikely because objects are only initialized once, near startup. So it put also less pressure on code handling errors :) (it is usually the least tested part of the code)
You mean for PyRun_InteractiveOneObject()? Oh, it can be made private, but what is the problem of adding yet another PyRun_Interactive*() function? There are already a lot of them :-) I also worked hard to support unencodable filenames: using char*, you cannot support arbitrary Unicode filename on Windows. That's why a added many various functions with "Object" suffix. Some examples: PyWarn_ExplicitObject(), PyParser_ParseStringObject(), PyImport_AddModuleObject(), etc. Some users complained that they were not able to run Python scripts on Windows with unencodable filenames (like russian characters on an english setup). I can try to find the related issues. |
New changeset 5e402c16a74c by Victor Stinner in branch 'default': New changeset cca13dd603a9 by Victor Stinner in branch 'default': New changeset 6348764bacdd by Victor Stinner in branch 'default': New changeset 954167ce92a3 by Victor Stinner in branch 'default': |
Another problem is that PyUnicode_FromString() failure is not handled correctly in some cases. PyUnicode_FromString() can fail because an decoder error, but also because of a MemoryError. For example, PyDict_GetItemString() returns NULL as if the entry does not exist if PyUnicode_FromString() failed :-( PyObject *
PyDict_GetItemString(PyObject *v, const char *key)
{
PyObject *kv, *rv;
kv = PyUnicode_FromString(key);
if (kv == NULL) {
PyErr_Clear();
return NULL;
}
rv = PyDict_GetItem(v, kv);
Py_DECREF(kv);
return rv;
} While working on failmalloc issues (bpo-18048, bpo-19437), I found some places where MemoryError caused tricky bugs because of this. Example of such issue: _PyDict_GetItemId() is more efficient: it only builds the Unicode string once. Before, PyDict_GetItemString() failure was not handled: structseq_new() could So moving from PyDict_GetItemString() to _PyDict_GetItemId() is for perfomances, but the main motivation is to handle better errors. I hope that the identifier will be initialized quickly at startup, and if its initialization failed, the failure is handled better... There is also a _PyDict_GetItemIdWithError() function. But it is not used currently (it was in changeset 2dd046be2c88). |
New changeset 40c73ccaee95 by Victor Stinner in branch 'default': New changeset 7177363d8c5c by Victor Stinner in branch 'default': New changeset dbee50619259 by Victor Stinner in branch 'default': New changeset 6a1ce1fd1fc0 by Victor Stinner in branch 'default': |
I changed the issue title to make it closer to the real changesets related to the issue. |
New changeset 77bebcf5c4cf by Victor Stinner in branch 'default': New changeset 3f9f2cfae53b by Victor Stinner in branch 'default': |
Usually CPython team avoids code churn without serious reasons. Performance reasons for the change PySys_GetObject("stdout") to _PySys_GetObjectId(&_PyId_stdout) are ridiculous. You changed hundreds lines of code for speed up interactive mode by perhaps several microseconds.
If there are bugs in code handling errors, they should be fixed in maintenance releases too.
And this is a problem. Newly added function is not even documented.
"One bug per bug report" as Martin says.
It can't fail on "stdout" because an decoder error. |
It can fail on "stdout" because of a memory allocation failure. |
Serhiy is right. You have to be responsible with the Py* namespace, and keep new functions private unless they are useful enough to the outside and you document them. In general, you changed lots of code without a single review. Can you slow down a bit? |
I created the issue bpo-19518 to discuss this part (but also to propose other enhancements related to Unicode). |
Well, using identifiers doesn't solve directly all issues. For example, _PyDict_GetItemId() should be replaced with _PyDict_GetItemIdWithError() to be complelty safe. It just reduces the probability of bugs. Using identifiers might add regressions for a minor gain (handling MemoryError better). As I did for issues bpo-18048 and bpo-19437 (related to issues found by failmalloc), I prefer to not backport such minor bugfixes to not risk a regression.
Again, performance is not the main motivation, please read again msg202293. Or maybe you disagree with this message? Sorry, I didn't explain my changes in first messages of this issue. I created the issue to group my changesets to an issue, to explain why I did them. I didn't expect any discussion :-) But thank you for all your remarks. |
New changeset 01c4a0af73cf by Victor Stinner in branch 'default': |
New changeset bf9c77bac36d by Victor Stinner in branch 'default': |
@georg, Serhiy, Martin: Sorry for having commits directly without more review. I didn't expect negative feedback on such changes, I thaught to moving from literal C byte string to Python identifiers was a well accepted practice since identifiers are used in a lot of places in Python code base. So what should I do now? Should I revert all changesets related to this issue, or can we keep these new identifiers and close the issue? |
No reaction, I close the issue. Reopen it if you still have complains ;-) |
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: