What are the savings from already having (today) "a frame", as opposed to (proposed) "a frame for this code"? If much of the work is to create "a frame", then it might be bad to reserve frames for only the function that created them. (i.e., is reinitializing a generic frame twice still faster than creating a new frame from scratch.) If it does make sense to create more frames, is there any reason they couldn't be tied to the code object by a weak reference? The reuse could still happen if there was no garbage collection in between, but code used in initialization won't keep its frames around forever. I suppose further tuning could protect frames from gc level < n, or "free" them back to a generic frame pool instead of a generic memory pool. -jJ
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