Greg Ewing schrieb: >>> Also it means you'd pay a penalty every time you >>> access it >> That penalty is already paid today. > > You'd still have that penalty, *plus* the > overhead of bit masking to get at the value. No, the penalty gets smaller if there is only a single type. For example, abstract.c now has if (res && (!PyInt_Check(res) && !PyLong_Check(res))) { PyErr_Format(PyExc_TypeError, "__int__ returned non-int (type %.200s)", res->ob_type->tp_name); Py_DECREF(res); return NULL; } Currently, if a long int is returned, it performs two subtype tests. If the long type is dropped, the second test can go away. In this specific code, there is no penalty for a representation flag, since the value is not accessed. Code that wants to support both int and long and needs the value often does PyLong_AsLong these days, which will support int as well. This currently reads if (vv == NULL || !PyLong_Check(vv)) { if (vv != NULL && PyInt_Check(vv)) return PyInt_AsLong(vv); PyErr_BadInternalCall(); return -1; } Notice that this has two checks if this is an int, and both are subtype checks. With a single type, this would become if (vv == NULL || !PyInt_Check(vv)) { PyErr_BadInternalCall(); return -1; } if (!vv->ob_size) return PyInt_AsLong(vv); Actually, the implementation of PyInt_AsLong might get inlined; it currently starts with a third PyInt_Check. So overall, I would expect that a single type would improve performance, not decrease it. As you say, any change is likely not noticeable in performance, though, either way. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4