How does docker image size impact runtime characteristics?

Question

I have constructed an image of a docker container. It is about 600MB. Let's refer to it as an image 'A'. Then I apply different cleaning (like 'apt clean') and size reduction steps (like 'rm man'), I get an image of 300MB in size. Let's refer to it as an image 'B'. As a result, image 'A' is the same as image 'B' but holds a lot of files which are never used during execution/runtime.

Note: I am aware that an image can be reduced in size if it is based on top of alpine-like base image, but let's say I can not do it due to various constraints.

I understand that:

• 'A' image requires more disk space than 'B' image to keep it in the local registry
• 'A' image takes more time to pull/push from a remote repo than 'B' image

I would like to know if the 'A' image has got any other impact on performance characteristics comparing with the 'B' image, especially:

• does the 'A' image take more time to start up (excluding pull time)?
• does the 'A' image use more RAM than the 'B' image (assuming the same workload)?
• does the 'A' image use more CPU than the 'B' image (assuming the same workload)?
• does the 'A' image use more disk space per every running container (assuming multiple containers are running from the same image)?
• does the 'A' image require more of anything else than the 'B' image may not require?

In general, I suspect the answer is No to all of the questions, but maybe I am wrong.

Answer 1

The size of the image it's only size of the directories. So it will never take more CPU or RAM (if you did not delete something, that will be loaded in RAM at startup from 'A') And a few words about pulling process: the image will be pulled from registry only first time and will be cached locally. Once you pull base image ('A') only differences will be pulled for image 'B'