Message325745
Something else this would need is a different name that better distinguishes it from the existing frozen modules, which freeze the bytecode rather than the resulting module state. (That existing approach avoids the stat overhead, but still incurs the module level bytecode execution overhead)
My suggestion would be to use the terms "preexec builtin module" and "preexec extension module", as the concept is similar to precompiled bytecode, just taken a step further: actually executing the module in advance and caching the result, not just compiling it.
This means the preexecuted module can't have any module level conditional logic that depends on runtime state if the resulting binary is going to remain portable across different environments, but there'd be a lot of standard library modules that could satisfy that constraint. |
|
Date |
User |
Action |
Args |
2018-09-19 10:56:53 | ncoghlan | set | recipients:
+ ncoghlan, nascheme, larry, eric.smith, eric.snow, xtreak |
2018-09-19 10:56:53 | ncoghlan | set | messageid: <1537354613.26.0.956365154283.issue34690@psf.upfronthosting.co.za> |
2018-09-19 10:56:53 | ncoghlan | link | issue34690 messages |
2018-09-19 10:56:53 | ncoghlan | create | |
|