What strace -c actually counts
strace -c prints a tidy table and people read the wrong column from it constantly.
% time seconds usecs/call calls errors syscall
61.24 0.048291 12 3921 read
22.10 0.017428 31 562 18 futex
9.83 0.007752 4 1804 writeseconds is time in the kernel, not elapsed time
It measures time spent inside the syscall. A process that is slow because it is burning CPU in userspace shows almost nothing here — the table will look calm while the program is on fire.
The overhead is not small
Every traced syscall takes two extra context switches. On a syscall-heavy workload strace can slow things by 10× or more, which changes the very timings you are reading. Treat the ratios as meaningful and the absolute numbers as suspect.
The errors column is the useful one
It is also the one nobody looks at. A pile of EAGAIN on a socket, or ENOENT from a library search path, will explain more real bugs than the timing columns ever will.
For production, reach for
perf trace or a bpftrace one-liner instead. Same questions, without stopping the process twice per syscall.