[Tim Peters] >> Resuming a generator function is a lot cheaper than calling a >> function, but there's still a non-trivial amount of code to get in >> and out of eval_frame() each time, which the listcomp version gets >> to skip. [Michael Hudson. > This is something that occurred to me a while ago: how many opcodes > does a typical invocation of eval_frame actually execute? A little > script told me that the median length of functions in Lib/*.py was 38 > instructions (or 52 bytes) IIRC, but obviously a dynamic count is far > more interesting. If the number is fairly small (and honestly, I have > no idea), the set up and tear down code becomes much more significant > than one might think. And whatever it is, I expect it will be significantly smaller for functions synthesized to implement generator expressions. > I didn't think much about the code to get *out* of eval_frame. There's a twist there: the functions synthesized for generator expressions get to take the quicker-than-general "fast_yield" exit path. Hmm! It looks like tests against WHY_YIELD before the fast_yield label can no longer succeed, but are still there to slow down non-generator cases.
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