[Python-Dev] Proposal: thread.get_dict
jim at zope.com
Wed Jun 30 06:16:32 EDT 2004
Jim Fulton wrote:
> Armin Rigo wrote:
> I have to say that I *really* like your suggestion of the thread.local
> object. I'm not sure the elegance isn't worth the extra dictionary lookup.
> Actually, for most apps, the elegance is more than worth the extra
> lookup. I'm gonna do some more investigation of this to see if I can
> the impact of the extra lookup on what I'm doing.
OK, I spent some quality time with gprof yesterday. I was able to prove to myself
that C dict lookups (e.g. PyDict_GetItem) are so fast that the extra dict lookup
isn't worth worrying about. (On my slow laptop, a lookup from a small dict took
about 80 nanoseconds.) I was being silly about the extra dict lookup cost.
Your local object is the way to go.
I'll also note that that I can use a slightly different implementation than the
one you suggested and gain back much of the (tiny) cost of the extra lookup.
It happens that lookup on non-string keys is much more expensive than lookup of
string keys. For small dictionaries (gprof experiments show that) using an
object key is more than 40% slower than using a string key. Tim tells me that
the difference will be more stark for a larger dictionary with collisions.
With the local object, the local-object implementation can control the key used.
Rather than using itself as the key for looking up its data dictionary, it can
use a string of it's address. This provides the safety of using an object
key, but gets the speed benefit of using a string key.
I'll send an updated proposal here later today.
Thanks for the great suggestion!
Jim Fulton mailto:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
More information about the Python-Dev