[Patches] [Patch #102337] revised CALL_FUNCTION implementation

[noreply@sourceforge.net]

Patch #102337 has been updated. 

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

Follow-Ups:

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