Question

I’m reviewing a server implementation that calls time(NULL) for each request being processed. I wonder what impact does calling time(NULL) has on a typical Linux system and if there are cheaper commands to determine the day — or in general how often would you call time()?

Thanks for your opinion on the topic.

Answer 1

It’s a system call, like the other answers said, and the other answers give you a good way of measuring the cost on your system. (Once in the kernel it doesn’t have to do much work, so it’s pretty close to the cost of pure syscall overhead. And Linux has done what it can to implement syscalls effectively. So in that sense, you can consider it pretty well optimized.)

Unlike the other answers, I wouldn’t consider this so cheap as to be automatically not worth worrying about. If this is in an inner loop, it depends on what else you’re doing in your inner loop. If this is a server processing requests, it’s probably making many syscalls per request, and one more will indeed not be much of a change in the cost of each request. However, I have seen code where the syscall overhead from calling time() (or gettimeofday(), which is what it really boils down to) does have a detrimental impact.

If you’re worried about the cost, the next thing to ask yourself is what cheaper ways of finding the time are available. In general, there’s not going to be a cheaper good way. If you’re on x86, you can ask the CPU with the rdtsc instruction (and there’s likely an analog on other cpu architectures) — that’s a single assembly instruction that’s not privileged so you can drop it into your code anywhere. But there are a lot of pitfalls — rdtsc doesn’t always increase at a predictable rate, especially if the cpu speed changes for power management, depending on which precise model of cpu you’re using; the values may not be synchronized across multiple cpus, etc. The OS keeps track of all this and will give you the friendly, easy-to-use version of the information when you call gettimeofday().