At 07:43 PM 12/5/2007 -0700, Neil Toronto wrote: >Phillip J. Eby wrote: > > At 10:48 PM 12/5/2007 +0100, Georg Brandl wrote: > >> Neil Toronto schrieb: > >>> So Jim and PJE finally convinced me to do it the right way. :) Thanks > >>> guys - it turned out very nice. > >> How does this relate to Armin Rigo's method cache patch? > >> > >> (http://bugs.python.org/issue1685986) > > > > Interesting. Armin's approach uses a single global cache of up to > > 1024 descriptors. That seems a lot simpler than anything I thought > > of, and might perform better by encouraging the processor to keep the > > descriptors in cache. It has a lot less pointer indirection, and has > > a dirt-simple way of invalidating a class' entries when something changes. > >Hey, I took out all my extra pointer indirection. :p > >FWIW, I like it. Though the hash should really incorporate the hash of >the type name as well as the attribute's so that sometype.method calling >othertype.method doesn't invalidate the cache. Locality makes the global >cache work, but locality also often means re-using the same names. Look at the patch more closely. The hash function uses a version number times the method name's hash. "Version" numbers are assigned one per class, so unless there are 2**32 classes in the system, they are uniquely numbered. The multiplication and use of the high bits should tend to spread the hash locations around and avoid same-name collisions. Of course, it's still always possible to have pathological cases, but even these shouldn't be much slower than the way things work now.
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