Linux online course

Measure Program and Script Execution Time in Linux

Learn how to use Linux time to measure command duration and interpret real, user, and system CPU time for commands and shell scripts.

Linux provides time for measuring how long a command or shell script takes to finish. It reports both elapsed duration and CPU usage, making it useful for comparing alternative commands, finding slow tasks, and checking whether a script change improved performance.

Execution-time measurement is a quick diagnostic, not a complete performance profile. A command can take a long time while using little CPU because it is waiting for storage, a network response, a lock, terminal input, or another process.

What the time command measures

Elapsed time and CPU consumption answer different questions:

• Elapsed time asks how long a user had to wait.
• CPU time asks how much processor time the process consumed.

The Linux time facility executes a command and prints timing statistics after that command finishes. The command's normal output is still produced normally; timing information is commonly written to standard error, the diagnostic output stream, rather than standard output.

Basic syntax

time command [arguments]

For example, time runs the command that follows it, passes that command its arguments, waits for completion, and then displays the timing report.

$ time sleep 2

The sleep command produces no normal output, but the timing facility prints a report after approximately two seconds. With a command that prints results, those results appear as usual before or around the final timing report.

Understanding real, user, and system time

A typical report looks similar to this:

real    0m0.245s
user    0m0.031s
sys     0m0.044s

Real time can be greater than user + system. For example, a program that reads a slow disk may use little CPU while most of its wall-clock time is spent waiting for I/O. CPU scheduling, network delays, locks, terminal input, and deliberate sleep intervals have similar effects.

CPU totals can also differ from real time in the other direction. A parallel or multi-process workload may use several CPU cores at once, so the sum of CPU time across work can be greater than the wall-clock duration. The exact accounting also depends on the shell or external implementation being used.

Measure a regular command with find

Prefix a find search with time:

time find . -name '*file*'

This searches from the current directory for names matching the pattern *file*. The arguments after time belong to find, not to the timing facility.

The quotes are important. They prevent the current shell from expanding the asterisks before find receives the pattern. The find command performs the name matching itself. The timing report appears only after the search completes, so a large directory tree may produce many matching paths before the report is printed.

Measure shell scripts

Run an executable script

If a script has execute permission and a valid interpreter declaration, commonly called a shebang, time it as an executable:

time ./script.sh

The script must be found at that path, be executable, and identify an appropriate interpreter in its first line. For example, a Bash script commonly begins with a Bash shebang. You can learn more about Bash in Bourne Again Shell Bash.

Invoke the interpreter explicitly

You do not need execute permission or a shebang when you explicitly invoke an interpreter:

time bash script.sh

This measures the Bash process while it runs the script. The measurement includes commands that the script waits for, such as external commands executed synchronously. It does not necessarily include work launched in the background that continues after the script itself exits.

For troubleshooting script paths, permissions, and file characteristics, Manage File Ownership provides related Linux file-management context.

Shell time versus external /usr/bin/time

Many shells provide time as a reserved word or built-in. This means the current shell implements it instead of starting an external executable. A commonly installed external implementation is /usr/bin/time, often GNU time.

These implementations can differ in supported options, output format, and exact behavior. Check which form your shell will use:

type time

The result may identify a shell keyword, built-in, function, alias, or external command. If an example requires GNU time options, invoke the external program explicitly:

/usr/bin/time find . -name '*file*'

Redirect command output and timing output

Standard output is the normal output stream produced by a command. Standard error is a separate stream commonly used for errors and timing reports. Because timing output normally uses standard error, redirecting standard output alone does not usually remove the timing report from the terminal.

To save the command's normal output and timing stream separately when using the shell's time facility, use separate redirections:

time find . -name '*file*' > matches.txt 2> timing.txt

Here, matching paths go to matches.txt, while standard error—including the timing report and any diagnostics—goes to timing.txt. If you need to distinguish timing from command errors, the external utility's output-file option is often clearer.

Use an external format and output file

On systems with GNU time, -f selects a format and -o writes timing information to a file:

/usr/bin/time -f 'elapsed=%e user=%U system=%S' find . -name '*file*'

/usr/bin/time -o timing.txt find . -name '*file*' > matches.txt

In the GNU format example, %e represents elapsed seconds, %U user CPU seconds, and %S system CPU seconds. These options are implementation-specific; verify support with the applicable manual page or help output.

Getting useful comparisons

A single timing result can be noisy. Repeat the same command several times and compare like-for-like runs:

• Use the same input files, arguments, working directory, and output destination.
• Run tests under similar system-load and network conditions.
• Record several results rather than selecting one favorable run.
• Consider cache state: a later filesystem read may be faster because data is already in memory.
• Avoid changing unrelated background activity between measurements.

For a quick duration check, time is usually enough. Repeatable benchmarking tools provide more systematic repetition and statistics, while profilers and tracing tools help identify where time is spent. Timing alone does not reveal which function, system call, script line, or child process is responsible for a slowdown.

Troubleshooting timing results

Unknown option or unexpected output

The shell's reserved word or built-in may be handling the command, or the external program may not be GNU time. Run type time, consult the relevant help or manual page, and use /usr/bin/time explicitly when its supported options are needed.

The script cannot be executed

A missing execute bit, invalid shebang, or incorrect path can prevent time ./script.sh from working. Try:

time bash script.sh

If that succeeds, correct the path, interpreter declaration, or permissions before using the executable form.

Timing data is mixed with output or missing from a file

Timing data normally uses standard error, while command results normally use standard output. Redirect the streams deliberately, or use /usr/bin/time -o timing.txt where supported. Remember that command errors also use standard error and may be stored with the timing report.

Repeated real times differ

Filesystem caching, disk activity, CPU contention, network conditions, process scheduling, and other background work can change wall-clock duration. Repeat the test under similar conditions and interpret a group of results rather than one run.

Real time is much larger than CPU time

This usually indicates waiting—for example, on I/O, a network response, a lock, a sleep interval, or CPU availability. It does not necessarily indicate inefficient CPU code. Use process monitoring or specialized profiling when you need to identify the specific source of the wait.

Practical checklist

1. Run type time if the implementation is unclear.
2. Start with time command [arguments].
3. Quote wildcard patterns that should be interpreted by the command, such as '*file*' for find.
4. Use time ./script.sh for an executable script or time bash script.sh for explicit interpretation.
5. Read real, user, and system as different measurements.
6. Use /usr/bin/time for external GNU time features when available.
7. Repeat measurements and control test conditions before drawing conclusions.

For command paths and shell behavior, see Show The Full Path Of Shell Commands. For related filesystem concepts, see File Structure In Linux.