Bash – Why bash time is more precise then GNU time

I'm assuming you understand that both these commands are calling a different version of time, right?

bash's built-in version

% time

GNU time aka. /usr/bin/time

% \time

The built-in time command to bash can be read up on here:

% help time
time: time [-p] PIPELINE
    Execute PIPELINE and print a summary of the real time, user CPU time,
    and system CPU time spent executing PIPELINE when it terminates.
    The return status is the return status of PIPELINE.  The `-p' option
    prints the timing summary in a slightly different format.  This uses
    the value of the TIMEFORMAT variable as the output format.

The GNU time, /usr/bin/time, is usually more useful than the built-in.

As to your precision problem it's covered here in this github gist, specifically:

Why is bash time more precise then GNU time?

The builtin bash command time gives milisecond precision of execution, and GNU time (usually /usr/bin/time) gives centisecond precision. The times(2) syscall gives times in clocks, and 100 clocks = 1 second (usually), so the precision is like GNU time. What is bash time using so that it is more precise?

Bash time internally uses getrusage() and GNU time uses times(). getrusage() is far more precise because of microsecond resolution.

You can see the centiseconds with the following example (see 5th line of output):

% /usr/bin/time -v sleep .22222
    Command being timed: "sleep .22222"
    User time (seconds): 0.00
    System time (seconds): 0.00
    Percent of CPU this job got: 0%
    Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.22
    Average shared text size (kbytes): 0
    Average unshared data size (kbytes): 0
    Average stack size (kbytes): 0
    Average total size (kbytes): 0
    Maximum resident set size (kbytes): 1968
    Average resident set size (kbytes): 0
    Major (requiring I/O) page faults: 0
    Minor (reclaiming a frame) page faults: 153
    Voluntary context switches: 2
    Involuntary context switches: 1
    Swaps: 0
    File system inputs: 0
    File system outputs: 0
    Socket messages sent: 0
    Socket messages received: 0
    Signals delivered: 0
    Page size (bytes): 4096
    Exit status: 0

More resolution can be had using bash's time command like so & you can control the resolution:

# 3 places 
% TIMEFORMAT='%3R'; time ( sleep .22222 )
0.224

From the Bash manual on variables:

TIMEFORMAT
The value of this parameter is used as a format string specifying how the timing information for pipelines prefixed with the time reserved word should be displayed. The ‘%’ character introduces an escape sequence that is expanded to a time value or other information. The escape sequences and their meanings are as follows; the braces denote optional portions.

%%
A literal ‘%’.

%[p][l]R
The elapsed time in seconds.

%[p][l]U
The number of CPU seconds spent in user mode.

%[p][l]S
The number of CPU seconds spent in system mode.

%P
The CPU percentage, computed as (%U + %S) / %R.

The optional p is a digit specifying the precision, the number of fractional digits after a decimal point. A value of 0 causes no decimal point or fraction to be output. At most three places after the decimal point may be specified; values of p greater than 3 are changed to 3. If p is not specified, the value 3 is used.

The optional l specifies a longer format, including minutes, of the form MMmSS.FFs. The value of p determines whether or not the fraction is included.

If this variable is not set, Bash acts as if it had the value

$'\nreal\t%3lR\nuser\t%3lU\nsys\t%3lS'
If the value is null, no timing information is displayed. A trailing newline is added when the format string is displayed.

I would have said that it is simply Tail Call Optimization, but in fact (as the last link points out), bash doesn't optimize tail calls. It only seems to optimize the case where the command to be executed is a simple command (that is, not a compound command).

The second command is not a tail call of pstree, because pstree is not the last thing in the command line. (It's a tail call of echo, but echo is usually a built-in so no subprocess will be created for it regardless.)

To save reading all those links (although I hope they are interesting), the idea is that if you know that a function/program/whatever will return immediately after calling some other function/program/whatever, and that the value returned will be the value returned by the called function/program/whatever, then you might as well just reuse the current stack frame (or process, in the case of a shell script) instead of pushing a new stack frame (creating a new process), calling the function (running the script), and then returning. In a shell script, you can do that manually by using exec for the last command, but it would be possible for the shell to do that automatically.

zsh and ksh both seem to be able to do that, but not bash:

$ zsh -c 'if [[ -n foo ]]; then pstree -s $$; else echo hello; fi'
init───lightdm───lightdm───init───konsole───bash───pstree
$ ksh -c 'if [[ -n foo ]]; then pstree -s $$; else echo hello; fi'
init───lightdm───lightdm───init───konsole───bash───pstree
$ bash -c 'if [[ -n foo ]]; then pstree -s $$; else echo hello; fi'
init───lightdm───lightdm───init───konsole───bash───bash───pstree

But that observation is just an observation, based on the versions of those shells which I happen to have installed, so YMMV:

$ zsh --version
zsh 5.0.2 (x86_64-pc-linux-gnu)
$ ksh --version
  version         sh (AT&T Research) 93u+ 2012-08-01
$ bash --version
GNU bash, version 4.2.45(1)-release (x86_64-pc-linux-gnu)