Expand direct calling to more C functions

[GoogleCodeExporter]

r890 added support for direct calls to fixed-arity functions with arity greater 
than METH_O. There are two things to do based on this patch:

1. Tag as many functions as possible with METH_FIXED. r890 only added a 
few, and there are lots more C functions that can benefit from this.

2. Add support for variadic C functions. This would allow direct calls to 
methods like dict.get() and unicode.replace().

Original issue reported on code.google.com by collinw on 5 Nov 2009 at 7:38

• Blocking: #105

[GoogleCodeExporter]

This work was inspired by http://bugs.python.org/issue1107887, which includes 
an 
implementation of the varargs support above.

Original comment by collinw on 5 Nov 2009 at 8:54

[GoogleCodeExporter]

I uploaded a patch for this issue at http://codereview.appspot.com/151055

Original comment by e...@4geeks.de on 8 Nov 2009 at 9:38

[GoogleCodeExporter]

I'm taking the liberty of reviewing this patch (as I was working on one 
myself), and
it looks good so far (as far as I can tell), but I just thought I'd mention that
there are many misindentations all over.

It seems to be mostly because of using spaces instead of tabs (as PEP7 
recommends for
pre-existing, tab-indented code), but there are other inconsistencies as well 
(for
example, on methodobject.c, line 42 should be indented to align with the column 
after
the opening parenthesis, on the line above).

Original comment by tioerre on 9 Nov 2009 at 12:40

[GoogleCodeExporter]

Thanks for your comments. I already wondered about certain strange entries in 
the
patch file. I'll fix the indentation asap.

I'm sorry to hear that you worked on a patch, too. Feel free to review in 
rietveld (I
hope this works without an explicit invite). If you have any larger addition 
just
email me, and we'll come up with a way to integrate them.

Original comment by e...@4geeks.de on 9 Nov 2009 at 1:31

[GoogleCodeExporter]

Direct calls for variadic calls were implemented in r894 by applying ebo's 
patch:

django:
Min: 0.874269 -> 0.850007: 2.85% faster
Avg: 0.876131 -> 0.854261: 2.56% faster
Significant (t=28.631433, a=0.95)
Stddev: 0.00526 -> 0.00554: 5.09% larger

slowpickle:
Min: 0.596070 -> 0.546111: 9.15% faster
Avg: 0.612642 -> 0.563118: 8.79% faster
Significant (t=4.020278, a=0.95)
Stddev: 0.08579 -> 0.08840: 2.95% larger

There are probably more functions that can be tagged with METH_ARG_RANGE (aka, 
the new METH_FIXED).

Original comment by collinw on 14 Nov 2009 at 12:31

[GoogleCodeExporter]

r904 tagged some more methods with METH_ARG_RANGE.

Highlight:

django:
Min: 0.868683 -> 0.847636: 2.48% faster
Avg: 0.874128 -> 0.854678: 2.28% faster
Significant (t=23.333001, a=0.95)
Stddev: 0.00617 -> 0.00561: 9.95% smaller

Other benchmarks were performance-neutral.

Original comment by collinw on 9 Dec 2009 at 6:10

[GoogleCodeExporter]

Original comment by collinw on 6 Jan 2010 at 11:44

• Removed labels: Release-2009Q4

[GoogleCodeExporter]

Per issue105, direct calling should be expanded to str.startswith().

Original comment by collinw on 11 Jan 2010 at 7:59

[GoogleCodeExporter]

How to find good targets for METH_ARG_RANGE: Run benchmarks directly with --
profile, e.g.,

PYTHONPATH=lib/django python2.6 performance/bm_django.py -n 100

That will give cProfile output for the Django benchmark. Look at which C 
functions 
are being called a lot. Do those functions take a fixed or variable number of 
positional arguments? If so, add METH_ARG_RANGE and benchmark with perf.py.

Lather, rinse, repeat.

Original comment by collinw on 21 Feb 2010 at 6:16

• Added labels: PyCon

[GoogleCodeExporter]

One good target would be cStringIO for the slow(un)?pickle benchmarks, I seem to
remember those are still METH_VARARGS.

Original comment by reid.kle...@gmail.com on 21 Feb 2010 at 6:55

[GoogleCodeExporter]

A number of methods on file are candidates as well.  We need a wrapper for 
argument 
checking/coercion though.

Original comment by alex.gay...@gmail.com on 21 Feb 2010 at 7:33

[GoogleCodeExporter]

Issue 143 is tracking what happens if you break out the code from getargs.c 
into 
functions so as to get consistent coercion of objects.

Original comment by bcannon on 25 Feb 2010 at 8:59