Repository navigation
Method cache #44760
Description
| BPO | 1685986 |
|---|---|
| Nosy | @arigo, @birkenfeld, @rhettinger, @jcea |
| Superseder | |
| Files |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/rhettinger'
closed_at = <Date 2008-01-12.13:16:06.765>
created_at = <Date 2007-03-22.13:47:53.000>
labels = ['interpreter-core']
title = 'Method cache'
updated_at = <Date 2008-10-13.11:45:16.021>
user = 'https://github.com/arigo'bugs.python.org fields:
activity = <Date 2008-10-13.11:45:16.021>
actor = 'jcea'
assignee = 'rhettinger'
closed = True
closed_date = <Date 2008-01-12.13:16:06.765>
closer = 'georg.brandl'
components = ['Interpreter Core']
creation = <Date 2007-03-22.13:47:53.000>
creator = 'arigo'
dependencies = []
files = ['7896']
hgrepos = []
issue_num = 1685986
keywords = ['patch']
message_count = 10.0
messages = ['52285', '52286', '52287', '52288', '52289', '52290', '52291', '52292', '58234', '59816']
nosy_count = 5.0
nosy_names = ['arigo', 'georg.brandl', 'rhettinger', 'jcea', 'bioinformed']
pr_nums = []
priority = 'normal'
resolution = 'duplicate'
stage = None
status = 'closed'
superseder = '1700288'
type = None
url = 'https://bugs.python.org/issue1685986'
versions = ['Python 2.4']
Activity
arigo commentedon Mar 22, 2007
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.
birkenfeld commentedon Mar 22, 2007
Perhaps Raymond, as one of the optimization specialists, can have a look in the meantime?
rhettinger commentedon Apr 3, 2007
Yes, I've got it from here.
bioinformed commentedon Apr 13, 2007
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:
Am I duplicating effort?
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).
Should this patch be targeted to Python 2.6 as well?
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.
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.
arigo commentedon Apr 13, 2007
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.
bioinformed commentedon Apr 13, 2007
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.
rhettinger commentedon Apr 13, 2007
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.
bioinformed commentedon Apr 13, 2007
Patch relative to current SVN HEAD uploaded as bpo-1700288.
rhettinger commentedon Dec 5, 2007
I'm working on this one this week.
birkenfeld commentedon Jan 12, 2008
Superseded by bpo-1700288, which is updated for 2.6.