On Wed, 2004-04-21 at 10:50, Phillip J. Eby wrote: > I could be wrong, but it seems to me that globals shouldn't be nearly as > bad for performance as builtins. A global only does one dict lookup, while > builtins do two. Also, builtins can potentially be optimized away > altogether (e.g. 'while True:') or converted to fast LOAD_CONST, or perhaps > even a new CALL_BUILTIN opcode, assuming that adding the opcode doesn't > blow the cacheability of the eval loop. The coarse measurements I made a couple of years ago suggest that LOAD_GLOBAL is still substantially slower than LOAD_FAST. Less than 100 cycles for LOAD_FAST and about 400 cycles for LOAD_GLOBAL. http://zope.org/Members/jeremy/CurrentAndFutureProjects/PerformanceMeasurements It would be good to repeat the measurements with current Python. I suspect it's a lot harder to figure out where to measure the start and stop times. The timestamps would need to be integrated with PREDICT and fast_next_opcode, for example. Jeremy
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