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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4