[Python-Dev] speeding up PyObject_GetItem

[Nick Coghlan]

Daniel Stutzbach wrote:
> 1) Assume the index is a PyLong until proven otherwise
> 
> The PyIndex_Check in PyObject_GetItem looks pretty useless.  If it
> returns false, PyObject_GetItem throws a type error.  If we skipped the
> PyIndex_Check when it would have returned false, PyNumber_AsSsize_t
> would later call PyIndex_Check and throw a type error.  Unless I'm
> missing something, this is a clear win and makes the code simpler.
> 
> In PyNumber_AsSsize_t, we could speed up the common case by trying
> PyLong_Check first, and if it fails then calling PyNumber_Index.  This
> change would make the common case faster, but make the code a few lines
> longer.

If this part can be done without losing any of the information currently
in the error messages, then it sounds like a decent idea.

> 2) Remove some of the exessive checking for NULL unless Py_DEBUG is defined
> 
> Many of the routines in abstract.c check their parameters for NULL, as a
> sanity check, and throw a SystemError if NULL is detected.  I'm tempted
> to suggest making these checks only when Py_DEBUG is defined, but I
> suspect if you wanted it that way, you would have changed it already. ;)
> 
> Assuming you really want the NULL checks in production Python, there are
> 5 checks for NULL even though there are only two parameters.  Seems like
> overkill?

The main problem is that many of these methods are not only used
internally, but are *also* part of the public C API made available to
extension modules. We want misuse of the latter to trigger exceptions,
not segfault the interpreter.

In theory you *could* create dual versions of the APIs, one without the
NULL check for internal use and one with the NULL check for the public
API, but that would get unmaintainable pretty fast (not to mention
speeding up the internal calls at the expense of potentially slowing
down calls from extension modules).

Redundant NULL checks within a single function are more promising
candidates for removal, but I don't believe that is happening here.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------