Skip to content

Conversation

freakboy3742
Copy link
Member

Although PYC files were being stripped to save space, it turns out it's significantly faster at runtime to have PYCs cached for use. This removes the __pycache__ exclusion from packaged artefacts.

PR Checklist:

  • All new features have been tested
  • All new features have been documented
  • I have read the CONTRIBUTING.md file
  • I will abide by the code of conduct

@freakboy3742
Copy link
Member Author

Ok... artefact size goes from 47MB to 129MB, so... that's a little too big. Stripping only .opt-1.pyc and .opt-2.pyc files still leaves the artefact at 72MB. That's a lot of space for speed...

@freakboy3742 freakboy3742 deleted the preserve-pyc branch March 19, 2025 04:44
@mhsmith
Copy link
Member

mhsmith commented Mar 19, 2025

Perhaps it would make more sense to leave the PYC compilation to the app build tool (e.g. beeware/briefcase#2073). We previously talked about this in the context of the app's own code, but it could apply equally to the standard library. And once a given support package has been compiled, the result can be cached and reused across multiple apps.

@freakboy3742
Copy link
Member Author

Yeah - I had a similar thought. Some other things that occurred to me:

  • Briefcase currently strips __pycache__ folders as well, so even if we did include pyc files in the distributed artefacts, Briefcase would strip them out again anyway. So - at the very least, there's a need to remove/alter that code, if not moving to an entire "compile pyc on build" setup.
  • Signatures make moving to a "compile pyc on build" setup a little more complicated, as the pyc content is inside the lib folder (for the macOS example, at least). I need to confirm this, but I think the right solution is to not sign frameworks that are being distributed for development purposes; the macOS framework in the Python installer is signed because it's part of the Python distribution, not because it's a framework.
  • There's an overlap here with the idea of stripping parts of the standard library that are not needed at runtime. If file size the is an issue, then providing an easy way to remove large parts of the standard library is one way to make the overhead of shipping PYC files a little less onerous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants