On 12/19/06, Andrea Griffini <agriff at tin.it> wrote: > > I'm experimenting with a patch for dictionary lookup caching, the > main idea being avoiding the lookup of a constant (co_names) in > a dictionary if the dictionary didn't change since last lookup. > > Currently the cache is held in a structure that is parallel to > co_names (the LOAD_GLOBAL opcode uses oparg to access > the cache slot) and this is wasteful if there are co_names entries > that are not used for global lookups. > > Probably I could act at the code object creation time to > sort names so that ones used by LOAD_GLOBAL are > at the beginning of co_names but this would require inspecting > and hacking the already generated opcode. > Another case that would IMO be worth optimizing is the > LOAD_ATTR lookup when it's done after a LOAD_GLOBAL > (I suspect that in many cases the element being searched will > be a module so caching would be simple to implement; for > general objects things are way more complex and I see no > simple solution for caching dictionary lookups). > > My opinion is that it would be by far better to do this ordering > of co_names at compile time but I've no idea where to look > for trying to make such a change. > > Can someone please point me in the right direction ? For guidance on how the compiler works, see PEP 339 ( http://www.python.org/dev/peps/pep-0339). -Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20061219/54c0ceb2/attachment.htm
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