[Patches] [Patch #102337] revised CALL_FUNCTION implementation

[noreply@sourceforge.net]

Patch #102337 has been updated. 

Project: python
Category: core (C code)
Status: Closed
Submitted by: jhylton
Assigned to : jhylton
Summary: revised CALL_FUNCTION implementation

Follow-Ups:

Date: 2001-Jan-04 06:05
By: jhylton

Comment:
revised version checked in
-------------------------------------------------------

Date: 2000-Dec-18 14:17
By: gvanrossum

Comment:
Back to Jeremy.  We had a code review session over the phone today.
-------------------------------------------------------

Date: 2000-Dec-18 08:29
By: jhylton

Comment:
Fixed bug in fast_cfunction (handling na > 1)

-------------------------------------------------------

Date: 2000-Dec-14 15:27
By: jhylton

Comment:
One more note: lemburg suggested using register declarations.  I didn't add
any because I don't know where they would help.  To experiment, I removed
all the register declarations from ceval.c and recompiled.  The results on
my function call benchmark were slightly better (difference was in the
noise).

-------------------------------------------------------

Date: 2000-Dec-14 15:19
By: jhylton

Comment:
The new version of the patch implements the new call dispatch approach
suggested by lemburg.  The basic idea is to have a separate function for
each kind of callable object (function, method, C function, etc.) and a
dispatch (call_object).

The CALL_FUNCTION implementation optimizes for two common cases -- builtin
C functions that use METH_OLDARGS (e.g. dict_keys, unicode_islower, etc.)
and Python functions and builtin methods that don't need special argument
handling.  Both of these common cases can be handled without creating an
argument tuple.

The function call code is much clearer, particularly in eval_code2, where
most of the complexity has been moved to separate functions.  The
performance is the same on the whole; calling builtins and bound methods is
a bit faster.

Also: the unused owner argument to eval_code2 was removed.

-------------------------------------------------------

Date: 2000-Nov-08 16:08
By: jhylton

Comment:
This is a first draft patch that revises the CALL_FUNCTION implementation. 
The first part of the revision breaks the long inline implementation into a
series of function calls.  Each of the function calls has some small local
optimizations (e.g. PyMethod_GET_SELF instead of PyMethod_GetSelf).

One problem that needs to be figured out is how these functions can cleanly
access the stack_pointer local var of eval_code2.  The current approach is
a bit messy.


-------------------------------------------------------

Date: 2000-Nov-08 16:29
By: jhylton

Comment:
A trivial fix to the logic keeps keyword arguments fast.

-------------------------------------------------------

Date: 2000-Nov-09 01:50
By: lemburg

Comment:
The patch looks ok, but I'm still missing the cleanup of the
PyEval_CallXXX() APIs which the patch I sent you included.

Some cosmetic issues:
1. your new APIs should be static and start with an underscore
  (e.g. _Py_CallFunctions)
2. you should add some "register" markers to the function call
  definitions -- this helps compilers such as gcc when inlining functions

-------------------------------------------------------

Date: 2000-Nov-09 05:59
By: nobody

Comment:
Haven't seen the patch yet, but one remark on static functions: these
should *not* have an underscore and *not* have a _Py_ prefix.

The _Py_ prefix is for stuff that cannot be static, because it needs to be
called from another file, but is not intended to be a public API (so it
could disappear or change in a future version without breaking user code).

There are a few exceptions (_Py_ functions that are part of the public
API); these are either historical accidents or need to be used with great
care only by wizards.

--Guido
-------------------------------------------------------

-------------------------------------------------------
For more info, visit:

http://sourceforge.net/patch/?func=detailpatch&patch_id=102337&group_id=5470