Revisited: Testing RPM build times - Part 2

In one of my previous blog posts, Revisited: Testing RPM build times - Part 1, I had indicated that I would be testing the build time of SNORT using an automated script. Well that didn't turn out too well. I had left it running overnight on my laptop and when I checked in the morning, my VirtualBox was not responding - it crashed. Of course, I lost all the data.

Anyway, I redid this test using aircrack-ng which is much faster to build because I honestly do not have much time to try SNORT again and wait with 7 courses + work + web design work. Besides, I need to use my laptop tonight and don't want to skewer the build time results.

Summary of my results:

The first, and very first time I ran rpmbuild -ba aircrack-ng, it took approximately 1 minute and 31 seconds. I ran it again after it had "warmed up" and I was surprised to see that it now took 43 seconds to complete.

From the results, using a -j1 value proved to be the fastest which correlates with the fact that my virtual machine is only using 1 CPU.

 

The Results:

-j1

real      0m43.798s

user     0m9.046s

sys       0m27.381s

 

-j2

real      0m45.369s

user     0m9.536s

sys       0m28.681s

 -j3

real      0m46.145s

user     0m9.595s

sys       0m29.114s

 

-j4

real      0m46.829s

user     0m9.774s

sys       0m29.842

Quick Notes

Quote on time output: real, user, sys from a site on the internet:

Real refers to actual elapsed time; User and Sys refer to CPU time used only by the process.

• Real is wall clock time - time from start to finish of the call. This is all elapsed time including time slices used by other processes and time the process spends blocked (for example if it is waiting for I/O to complete).

• User is the amount of CPU time spent in user-mode code (outside the kernel) within the process. This is only actual CPU time used in executing the process. Other processes and time the process spends blocked do not count towards this figure.

• Sys is the amount of CPU time spent in the kernel within the process. This means executing CPU time spent in system calls within the kernel, as opposed to library code, which is still running in user-space. Like 'user', this is only CPU time used by the process. See below for a brief description of kernel mode (also known as 'supervisor' mode) and the system call mechanism.