[Python-Dev] Proposal: thread.get_dict

[Jim Fulton]

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 
> dictionary
> lookup.  I'm gonna do some more investigation of this to see if I can 
> estimate
> 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

-- 
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