[Patches] [ python-Patches-1685986 ] Method cache

[SourceForge.net]

Patches item #1685986, was opened at 2007-03-22 13:47
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1685986&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Armin Rigo (arigo)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Method cache

Initial Comment:
This is a port of PyPy's method cache optimization.  It gives a very good speed-up to PyPy, and it is simple enough to be attempted on CPython.

The patch is against Python 2.4, which is the version I still use; I've applied the patch on the system-wide Pythons of a couple of machines a few days ago and haven't had any problem since.  It gives a consistent 20+% of speed-up on all applications and benchmarks I tried, and up to 36% in extreme OO examples like the "richards" benchmark.

The patch needs to be ported to the HEAD, and it needs some extra careful review.  I'm a bit too busy right now to do any of these but I'll eventually come back to it if nobody else does.


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

>Comment By: Armin Rigo (arigo)
Date: 2007-04-13 14:32

Message:
Logged In: YES 
user_id=4771
Originator: YES

About 4.: type_modified() calls are needed when either the mro or the
dictionary of any type along the mro is modified.  I guess that an example
can be built with a class X, where X().__module__ is read twice but
X.__module__ modified inbetween.

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

Comment By: Kevin Jacobs (bioinformed)
Date: 2007-04-13 13:38

Message:
Logged In: YES 
user_id=1768698
Originator: NO

I've done some work on this patch, including porting it to HEAD,
streamlining some aspects for comprehensibility, and verifying correctness.
 My performance results are a little less dramatic, ranging from 10% speed
up for simple non-heavy OO code to about 25% for applications with deeper
object hierarchies.  Given the very attractive speed up, I'm happy to
continue along this patch, but have a few questions for both Raymond and
Armin:

1. Am I duplicating effort?

2. Should this optimization be targeted only toward the Py3k branch, as
some of the trickier logic goes away (no old style classes to complicate
things).

3. Should this patch be targeted to Python 2.6 as well?

4. Armin, can you explain why a type_modified call is needed in the
__module__ setter?  I don't immediately see how this affects the mro.

5. A minor nit: I'm not thrilled that the has version tag is cleared when
the type has an unsupported base class/mro.  I realize why this is
convenient, but it bothers me because __bases__ is mutable and the flag
cannot be reset once unset.  I realize this is possibly a vanishingly rare
case (__bases__ is not likely to be reset often) and that correctness is
not at stake.  Regardless, I'd be interested in exploring strategies that
do not add more flags or complexity, but also allow for types to recover
their valid version status after unsupported bases in the mro are removed.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-03 01:44

Message:
Logged In: YES 
user_id=80475
Originator: NO

Yes, I've got it from here.

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

Comment By: Georg Brandl (gbrandl)
Date: 2007-03-22 15:28

Message:
Logged In: YES 
user_id=849994
Originator: NO

Perhaps Raymond, as one of the optimization specialists, can have a look
in the meantime?

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1685986&group_id=5470