Neil Toronto added the comment:
There's nothing it tests that standard unit tests don't, so it shouldn't
stick around as a unit test. I used it to time different types of
attribute lookups and left it in as an optimization aid.
The main test groups are '.' access, successful hasattr (returns
Neil Toronto added the comment:
Well horse pucky. I plum forgot about deletes.
I've attached an update that properly clears the cache entry for the
deleted attribute for all non-shadowing subclasses. (It was a small
change.) Undef'ing ATTRCACHE_SETATTR_INVALIDATES should work now.
Re
Neil Toronto added the comment:
Yes, as well #1700288 (Armin's attribute lookup caching patch ported to
2.6) or #1685986 (Armin's original for 2.4), or whatever Raymond finds
most convenient.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1560
Neil Toronto added the comment:
Sorry - I'll be more clear. I'd love to see 2.6 get attribute lookup
caching, and Kevin's port (#1700288) of Armin's original 2.4 patch
(#1685986) does that for 2.6. #1685986 (2.4) should be closed and
#1700288 (2.6) should remain open. But Raymond has indicated
New submission from Neil Toronto:
This is a half-port of the patches in #1685986 and #1700288 to Python
3.0. Speedups are about the same as in those patches applied to their
respective Python versions for minibenchmarks (included in the patch as
fastattr_test_py3k.py): 5%-30% or more depending
Neil Toronto added the comment:
This patch adds the ability to invalidate all of a subclasses' cache
entries upon setattr rather than updating just one cache entry. It's not
clear which of these is the Right Thing To Do, so I've made it an #ifdef
for now. It defaults to updating.
Added file
Neil Toronto added the comment:
Attribute access that happens only once or very infrequently probably
shouldn't go through the cache machinery - it'll only slow things down.
(Updating slots for example.) Maybe _PyType_Lookup should remain the
same, with _PyType_CachingLookup added for attribute
Neil Toronto added the comment:
I've attached the microbenchmarks I was using for my own version of
attribute caching. For list, tuple, dict, and a deep hierarchy, it tests
accessing type attributes (cls.__class__), class attributes
(cls.__init__), class attributes via instance (inst.__class__
Neil Toronto added the comment:
Christian: Thanks for that, I'll have to remember DEBUG_LEAK in the
future. :)
It looks like it may be acting correctly since there *is* now a
fastglobals object that needs collecting, and also a new tuple built
from co_names + __builtins__. I don't know why
So I've recently had a stroke of insanity, deciding that what the
open-source Quake III engine *really* needs is a good, healthy dose of
Python.
Here's the quick version: The Q3 engine is split into the engine
(responsible for rendering, sound, networking, input, and collision
detection) and
10 matches
Mail list logo
