On 2016-06-20 02:29, Brett Cannon wrote: > > On Sat, 18 Jun 2016 at 21:49 Guido van Rossum <guido at python.org > <mailto:guido at python.org>> wrote: > [snip] > > Could you figure out some other way to store per-code-object data? > It seems you considered this but decided that the co_extra field was > simpler and faster; I'm basically pushing a little harder on this. > Of course most of the PEP would disappear without this feature; the > extra interpreter field is fine. > > Dino and I thought of two potential alternatives, neither of which we > have taken the time to implement and benchmark. One is to simply have a > hash table of memory addresses to JIT data that is kept on the JIT side > of things. Obviously it would be nice to avoid the overhead of a hash > table lookup on every function call. This also doesn't help minimize > memory when the code object gets GC'ed. > [snip] If you had a flag in co_flags that said whether it should look in the hash table, then that might reduce the overhead.
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