Should __pycache__ folders be included in production containers?

Question

I am wondering if keeping __pycache__ folders and .pyc files in built containers is good or bad practice.

On one side you want to minimize the size of the containers but on the other side you do not want to slowdown the container executions either.

Considering that python interpreter is static these files can also be considered static.

Did anyone made some performance tests and came to a conclusion?

Answer 1

Personally, I don't use __pycache__/.pyc files in containers if at all possible. More specifically, I try to build and run my containers such that they never generate the .pyc files (setting the environment variable PYTHONDONTWRITEBYTECODE=1 and passing --no-compile --no-cache-dir to all pip invocations, explicitly, or via pip.conf or equivalent environment variables), either during build or at runtime.

The advantage of cached bytecode is in startup time, not execution speed; import takes longer, but actual execution is just as fast (the bytecode is still there in memory, just not on disk). But in the case of containers, making the container larger means it takes longer to cache and launch, so you're wasting disk space and any gains in Python launch time are typically offset by delays pulling and launching the container in the first place. And writing out bytecode at runtime is pointless; it'll be lost when the container shuts down, so it's adding expense to startup for no benefit.

Having the .pyc files for the base install of Python itself isn't so bad (though as noted in the comments, the official Dockerfiles expunge them); with many containers depending on them, the odds of the base Python image already being cached is high, and many pre-built Python images already have them (so deleting them after the fact wouldn't help), and it does reduce start up time a little for programs running in containers built on them. But for per-container third party installs, you're just getting bloat with no compensating benefit.