| msg52285 - (view) |
Author: Armin Rigo (arigo) *  |
Date: 2007-03-22 13:47 |
| 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. |
|
|
| msg52286 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2007-03-22 15:28 |
| Perhaps Raymond, as one of the optimization specialists, can have a look in the meantime? |
|
|
| msg52287 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2007-04-03 01:44 |
| Yes, I've got it from here. |
|
|
| msg52288 - (view) |
Author: Kevin Jacobs (bioinformed) |
Date: 2007-04-13 13:38 |
| 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. |
|
|
| msg52289 - (view) |
Author: Armin Rigo (arigo) * |
Date: 2007-04-13 14:32 |
| 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. |
|
|
| msg52290 - (view) |
Author: Kevin Jacobs (bioinformed) |
Date: 2007-04-13 14:43 |
| Thanks for the reminder, Armin. I've been focusing on verifying correctness for cached unbound methods, not all attributes. I'll re-review for that more general case. |
|
|
| msg52291 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2007-04-13 16:34 |
| Also, if you've updated the patch to apply to the head, please upload it to SF so I won't have to do the same thing. |
|
|
| msg52292 - (view) |
Author: Kevin Jacobs (bioinformed) |
Date: 2007-04-13 19:17 |
| Patch relative to current SVN HEAD uploaded as #1700288. |
|
|
| msg58234 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2007-12-05 22:58 |
| I'm working on this one this week. |
|
|
| msg59816 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2008-01-12 13:16 |
| Superseded by #1700288, which is updated for 2.6. |
|
|