Reducing image size strategies in Docker - Time & Space Complexity
We want to understand how the time to build a Docker image changes when we apply strategies to reduce its size.
How does the build time grow as the image layers or files increase?
Analyze the time complexity of the following Dockerfile snippet.
FROM python:3.12-slim
COPY requirements.txt ./
RUN pip install --no-cache-dir -r requirements.txt
COPY app/ ./app/
RUN rm -rf /var/lib/apt/lists/*
CMD ["python", "./app/main.py"]
This Dockerfile installs dependencies and copies app files, then cleans cache to reduce image size.
Look for repeated or costly steps in the build process.
- Primary operation: Installing packages from requirements.txt (pip install).
- How many times: Once per build, but depends on number of packages listed.
The build time grows as the number of packages and files increases.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 packages/files | Low operations, fast build |
| 100 packages/files | About 10 times more operations, longer build |
| 1000 packages/files | Much longer build time, many more operations |
Pattern observation: Build time increases roughly in proportion to the number of packages and files processed.
Time Complexity: O(n)
This means the build time grows linearly with the number of packages and files included in the image.
[X] Wrong: "Removing cache files after installation makes the build time faster."
[OK] Correct: Removing cache reduces image size but does not speed up the installation step itself, so build time stays about the same.
Understanding how build time scales with image content helps you design efficient Dockerfiles and explain trade-offs clearly in real projects.
What if we split the installation of packages into multiple RUN commands? How would the time complexity change?