When running time on process/application, it seems like it always cache the result/process, and thus doesn't give the real timing of the process.

I tried:

sync; time process


sync -f; time process

but it seems it doesn't really disable caching.

By running time process or as the above example sync -f; time process, sync; time process repeatedly, it can be noticed that the running time change (which i suspect is because of caching).

Any way to really disable caching to give real time of process?

  • Could you perhaps give some examples, or explain why you get the impression that a process took longer (or should take longer) than what time shows? Does the same effect happen with time sleep 1? Sep 8 '20 at 19:19
  • try to launch the command time sleep 1 or even time date repeatedly, and you'll notice that the displayed time information change at some point (because as i suspect, of caching...). The same thing happen with the example i gave in my post (using sync/sync -f). Sep 8 '20 at 19:21
  • disabling caching/or just knowing the real running time of a process/application is very important, especially if you're making application yourself, which is why I'm asking (though the example i gave aren't things i made myself, but they illustrate what i mean). Sep 8 '20 at 19:23
  • The caching is not of the process. In is of disk access. Try the nocache tool it works as a command prefix in the same way that time does. Sep 8 '20 at 22:12

time shows the resource usage for its child process, as measured by the kernel; it uses getrusage to do so (on Linux, this is implemented using wait4. It measures the real time used by the particular execution being measured.

Variations you see reflect variations which occur during process execution. They have a large variety of causes, typically involving resource contention of one kind or another. Like any benchmark, the use of time only makes sense in a pre-defined scenario.

Trying to measure the execution time of a command without any external influence is (mostly) possible, but it requires a lot of work to set up. On Linux, you can flush all disk caches beforehand:

echo 3 > /proc/sys/vm/drop_caches

(The effects of running a process aren’t cached anywhere else, except in CPU caches to a small extent, unless the process itself performed its own memoisation so that it will do less work if run again — e.g. a compiler with ccache. You’d presumably know whether your own application does this.)

You can also run the command you wish to measure on a dedicated CPU, otherwise unused by the kernel, so it won’t be affected by interrupts or rescheduling, and less affected by cache flushes. Other factors to bear in mind include CPU frequency variations, hyperthreading, address space randomisation...

One of my colleagues, Victor Stinner, has written up his notes and links on the topic of benchmarking, focusing on Python benchmarking; one link which provides a good set of adjustments to make is Denis Bakhvalov’s guide to getting consistent results on Linux.

  • Nicely detailed post! Didn't knew the bit about ccache and space randomisation, and the linked post are also well written. Sep 8 '20 at 21:26

You can try disabling dirty caches completely though it may lead to quite unpleasant effects, i.e. your write speed could be severely affected because they allow the kernel to optimize write operations, e.g.:

sudo sysctl vm.dirty_background_bytes=4096
sudo sysctl vm.dirty_bytes=8192

A good write up on caching: https://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/

  • The two command you mentioned seems to throw the same error: sysctl: setting key "vm.dirty_background_bytes": Invalid argument sysctl: setting key "vm.dirty_bytes": Invalid argument Sep 8 '20 at 21:29
  • I'm using linux :)! Ubuntu 19.04 to be precise. Sep 8 '20 at 21:58
  • 1
    @NordineLotfi Sorry, looks like setting 0 is not supported, 4096 is the minimum. :-) Sep 8 '20 at 21:58
  • This time it seems to work for sudo sysctl vm.dirty_background_bytes=4096 but not the other one (have the same error as i posted above). Sep 8 '20 at 22:00
  • 1
    Try 8192. Looks like there's a limit on how low you can go :-) 4096 and 8192 work here. Sep 8 '20 at 22:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.