[Python-Dev] Special-casing "O"

[Tim Peters]

[MAL]
> If we end up only optimizing the re.match("O+") case, we wouldn't need
> the METH_SPECIAL masks; a simple METH_OBJARGS flag would do the trick
> and Martin could call the underlying API with one or more PyObject*
> taken directly from the Python VM stack.

How then does the callee know it was called with the correct # of arguments?
By adding enough pointer arguments to cover the longest possible O+ string
plus 1, then verifying that the one just beyond the last one it expects is
NULL, while the ones before that are not?  Adding another "# of arguments"
member to the method table?  Inventing METH_O, METH_OO, METH_OOO, ...?

> In that case, please consider at least supporting "O", "OO" and "OOO"
> with optional arguments treated like I suggested in an earlier
> posting (simply pass NULL and let the API take care of assigning
> a default value).
>
> This would take care of most builtins:

You don't have to convince me that cases other than plain "O" exist.  What's
missing is data in support of the idea that calls to those are relatively
frequent enough that it's a NET win to slow plain "O" in order to speed the
additional cases when they happen.  For example, it's not possible for calls
to reduce() to have a high hit rate in real life, because builtin_reduce is
a very expensive function -- there's only so many of those you can cram into
a second even if the calling overhead is 0.  OTOH, add a single branch to
the time it takes to find builtin_type and you've slowed its *total*
execution time significantly.

The implementation of METH_O alone is a pure win by any measure.  So would
be implementing METH_OO alone, or METH_OOO alone, etc.  Mix them, and they
all get slower than they could have been.  All the data we have says METH_O
is the single most important case, and that jibes with common sense, so I
believe it.

If you want to speed everything, fine, do that, but that likely requires a
preprocessing phase so that type signatures don't have to be resolved at
runtime at all.  So long as we're just looking at simple hacks, "the simpler
the better" is good advice and should rule in the absence of compelling
evidence against it.