This is done to simulate real-world performance. Your binary is not the only binary in the system and other services may be running as well. So fastest time is the happiest path and slowest is the unluckiest.
The range of remaining three is what you expect to get 99% of the time on a real world system.
Any production where you're routinely scanning a text file with a million records is probably a batch process, and I'd be shocked if the usual performance wasn't much closer to the worst case than the average.
But this is a contrived test, and looking for the fastest solution, so your arguments point to taking the fastest: the one with the least interference.
Yes, the one works the fastest in average case will be the fastest in the real world, and will be the one least affected by general noise present in the system.
I agree that this method will produce a better estimate of expected mean real world performance under certain load conditions, but still contend it just muddies the waters about which solution is in fact the fastest.
Not necessarily. A good code with nice parallelization and efficient code path will always win. If the code is inefficient to begin with, having no cron jobs at the same time won't help.
> Your binary is not the only binary in the system and other services may be running as well.
Technically yes, but these days most of my machines are single purpose VMs; database/load balancer/app server/etc, so it still seems weird not to take the fastest.
Then, your VM is not the only VM sharing the bare metal. Same thing applies, only on a slightly higher level.
As long as you share the metal with other stuff (be it containers, binaries, VMs), there's always competition for resources, and your average time becomes your real world time.
Physical memory is not fungible like that across VMs. So, you can expect stuff loaded into memory to stay there unless your kernel inside the VM decides it not to.
No, it's. VirtIO's balooning device can "inflate" to pseudo-allocate memory on a VM to free physical memory for other hosts.
Moreover, even if your files in memory, you cannot reserve "memory controller bandwidth". A VM using tons of memory bandwidth or a couple of cores in the same NUMA node with your VM will inevitably cause some traffic and slow you down.
There's logrotate and other cleanup tasks, monitoring, dns, a firewall, and many more stuff running on that server. No matter how much you offload to the host (or forego), there's always a kernel and supporting deamons running alongside or under your app.
The range of remaining three is what you expect to get 99% of the time on a real world system.