> The simplest test I can think of (`docker run busybox true`) takes 0.38s wall clock, pretty far out from your statement even when allowing for it stopping as well.
Good to know. The milliseconds claim is on their website, I took it for granted and never timed it. I guess they consider anything under 1 second as "milliseconds" :) But actually the stopping time could be a factor.
When the process executable path is located on a networked filesystem - cached data for that file must be thrown away by the OS once the file lock is released (which happens when the process exits). So you will actually speed up subsequent launches of the process if you delay your shutdown a little bit such that the file lock is held and thus the system cache for that file is not thrown away. They probably aren't doing this though...
Good to know. The milliseconds claim is on their website, I took it for granted and never timed it. I guess they consider anything under 1 second as "milliseconds" :) But actually the stopping time could be a factor.
When the process executable path is located on a networked filesystem - cached data for that file must be thrown away by the OS once the file lock is released (which happens when the process exits). So you will actually speed up subsequent launches of the process if you delay your shutdown a little bit such that the file lock is held and thus the system cache for that file is not thrown away. They probably aren't doing this though...