[issue23723] Provide a way to disable bytecode staleness checks

Brett Cannon added the comment: I realized that importlib.abc.SourceLoader.path_stats() provides a way to override stat collection and basically hard-code the stat number for all files from an import perspective. So if people simply generated their bytecode with a static timestamp and

[issue23723] Provide a way to disable bytecode staleness checks

Brett Cannon added the comment: Skipping the source stat makes no difference in startup time even if you import django.http as part of the work. This would definitely be mostly for people who launch so many processes that they actually gain from collecting microseconds worth of benefit from

[issue23723] Provide a way to disable bytecode staleness checks

Changes by Raúl Cumplido raulcumpl...@gmail.com: -- nosy: +raulcd ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23723 ___ ___ Python-bugs-list

[issue23723] Provide a way to disable bytecode staleness checks

Brett Cannon added the comment: I haven't thought about how to implement it, let alone document it. As I said, I might simply refactor importlib so that others can at least implement a loader which can do this without having to directly muck with importlib itself. It really depends on how far

[issue23723] Provide a way to disable bytecode staleness checks

Antoine Pitrou added the comment: Can you please provide timing numbers? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23723 ___ ___

[issue23723] Provide a way to disable bytecode staleness checks

Serhiy Storchaka added the comment: Wouldn't zipimport provide better performance? If bytecode generation is thoroughly controlled, could you collect your .pyc files in a ZIP file? -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org

[issue23723] Provide a way to disable bytecode staleness checks

Brett Cannon added the comment: What Greg said. =) Basically it would allow those who know what they are doing to cut out a stat call per load. I suspect anyone deploying to a server is in a similar situation where they are not actively editing the code once deployed, and so saving on the

[issue23723] Provide a way to disable bytecode staleness checks

Gregory P. Smith added the comment: We already use zipimport for most production deployments. It works well. We've modified our own zipimport to ignore timestamps as keeping them in sync between pyc and py files in the zip files own timestamps is painful. Unfortunately the stdlib zipimport

[issue23723] Provide a way to disable bytecode staleness checks

Antoine Pitrou added the comment: That sounds kind of reasonable, but how are we supposed to document this? Or is this only a secret backdoor for people in the know? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23723

[issue23723] Provide a way to disable bytecode staleness checks

New submission from Brett Cannon: In environments where bytecode generation is thoroughly controlled, it would be nice if there was a way to specify that the bytecode file is externally guaranteed to be up-to-date, and thus skip any stat call involving bytecode verification. Could be

[issue23723] Provide a way to disable bytecode staleness checks

Antoine Pitrou added the comment: What is the benefit? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23723 ___ ___

[issue23723] Provide a way to disable bytecode staleness checks

Gregory P. Smith added the comment: This would avoid the need to modify an interpreter to have this optimization. In this mode the potentially expensive stat() call is avoided. No need to ensure that the pyc file's embedded timestamp matches the py file's timestamp. The only use of this