[Python-Dev] Special-casing "O"

M.-A. Lemburg mal@lemburg.com
Sun, 27 May 2001 12:26:27 +0200


"Martin v. Loewis" wrote:
> 
> > To call these, the calling mechanism would have to cast these
> > to:
> >
> >       foo(void *, void *, void *)
> >       bar(void *, void *, void *, void *, void *)
> >
> > Wouldn't this work ?
> 
> I think it would work, but I doubt it would save much compared to the
> existing approach. The main point of this patch is to improve
> efficiency, and (according to Jeremy's analysis), most of the time for
> calling a function is spend in PyArg_ParseTuple. So if we replace it
> with another interface that also relies on parsing a string, I doubt
> we'll improve efficiency.

That's the point: we are not replacing PyArg_ParseTuple()
with another parsing mechanism, we are only using PyArg_ParseTuple()
as fallback solution for parser strings for which we don't
provide a special case implementation.

The idea is to simply do a strcmp() (*) for a few common
combinations (like e.g. "O" and "OO") and then provide the
same special case handling like you do with e.g. METH_O.
The result would be almost the same w/r to performance
and code reduction as with your approach. The only addition
would be using strcmp() instead of a switch statement.

The advantage of this approach is that while you can still
provide special case handling of common parser strings, you
can also provide generic APIs for most other parser strings
by reverting to PyArg_ParseTuple() for these.

> IOW, I won't implement that approach. If you do, I'd be curious to
> hear the results, of course.

I'll see what I can do...

> P.S. There would be still cases where PyArg_ParseTuple is needed,
> e.g. for "O!".

True... can't win 'em all ;-)

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
______________________________________________________________________
Company & Consulting:                           http://www.egenix.com/
Python Software:                        http://www.lemburg.com/python/