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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
