Introduction

I've been fine-tuning code to reduce processing from 30 seconds to under a second in various parts of my bash program. I'm having trouble wrapping my mind about how the time command works when it reports real, user and sys variables.

I have this code:

echo " "
echo "Time to build DirsNdxArr from DirsArr $DirsArrCnt elements:"
DirsArrCnt=${#DirsArr[@]}
time for (( i=1; i<$DirsArrCnt; i=i+$DaElementCnt )); do DirsNdxArr["${DirsArr[$i]}"]=$i AllItemSizes=$(( $AllItemSizes + ${DirsArr[$(( $i + $ColFileSizes - 1 ))]} ))
done
echo " "
echo "Time to build FilesNdxArr from FilesArr $FilesArrCnt elements:"
FilesArrCnt=${#FilesArr[@]}
time for (( i=0; i<$FilesArrCnt; i=i+$FaElementCnt )); do FilesNdxArr["${FilesArr[$i]}"]=$i AllTagSizes=$(( $AllTagSizes + ${FilesArr[$(( $i + $FaColFileSizes ))]} ))
done

That reports this:

Time to build DirsNdxArr from DirsArr 56700 elements:
real 0m0.149s
user 0m0.149s
sys 0m0.000s
Time to build FilesNdxArr from FilesArr 390 elements:
real 0m0.002s
user 0m0.002s
sys 0m0.000s

Why is sys time reporting zero?

Interpreting the output of time builtin command one would assume the system is doing nothing but surely this isn't what is happening?

ps I know \n can be used as a new-line to echo with -e parameter. My habit is to sacrifice one liner-cuteness and fringe arguments in favor of readability.

17

1 Answer

Long story short, it simply means that your program didn't request to perform any privileged tasks, hence CPU has spend no time in the privileged (kernel) mode.

Basics First

First of all, there's several things you need to understand in order to interpret the output of time properly:

• which time command you're running (because there's multiple)
• the meaning of each field and what each one of them means (extra reading here)
• the difference between kernel and user mode

There's two types time command. There's shell built-in and there's /usr/bin/time. The shell built in is the one that you're using and it defaults to showing 3 lines, real, user,and sys. The manual for time also mentions this same form of output:

 -p, --portability Use the following format string, for conformance with POSIX standard 1003.2: real %e user %U sys %S

And if you check the "FORMATTING THE OUTPUT" section we have:

 E Elapsed real (wall clock) time used by the process, in [hours:]minutes:seconds. U Total number of CPU-seconds that the process used directly (in user mode), in seconds. S Total number of CPU-seconds used by the system on behalf of the process (in kernel mode), in seconds.

From all this info we can gather that there's two modes in which CPU can run - user mode and kernel mode, and the time command displays how long CPU remains in a given mode to do whatever your program/app has asked CPU to do.

Understanding what is sys time reporting and what does 0 value mean

OK, so we understand the difference is that there's user mode and kernel mode in which code can run. We already can figure that this basically means the program didn't use kernel mode for executing some tasks. What does that actually mean ?

Refer to this post:

In Kernel mode, the executing code has complete and unrestricted access to the underlying hardware. It can execute any CPU instruction and reference any memory address.

And from another answer on the same post:

The switch from user mode to kernel mode is not done automatically by CPU. CPU is interrupted by interrupts (timers, keyboard, I/O). When interrupt occurs, CPU stops executing the current running program, switch to kernel mode, executes interrupt handler. This handler saves the state of CPU, performs its operations, restore the state and returns to user mode.

So that's what your output means - there was no switch to kernel mode and CPU did not receive any interrupts from the program to do so. This also means that your code doesn't have anything that would require elevated privileges from CPU

Note: this probably should be rephrased as "there was no long/noticeable switch into kernel mode", since allocating memory with something like malloc() function in C would require switching into kernel mode, but these are microscopic switches, which we'd really have to investigate with a debugger or strace command.

1

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

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