RE: utility to time queries

-----Original Message----- From: Mark D. Stock [mailto:mdstock@mydas.freeserve.co.uk] >> Depending on the OS and command line you are using you should use time (the >> shell >> builtin) 'cos it can more accurately track across process boundaries > >I think you'll find that on most modern Unices, timex is a link to time. >;-) Hmmm, not under this install on Solaris it isn't, totally different binaries. AFAIR the same is true under AIX, the AIX performance tuning guides, the internal IBM ones, have a large section explaining why you should use sh (ksh) builtin time for timing piped commands and not the /usr/bin ones. The ksh shell builtin is the same as /usr/bin/time, it makes the same calls to with the exception that it can also time other built-in commands in the pipeline. Under csh you get yet another shell built-in, which reports an additional three fields (under Solaris), these never used to be populated correctly. I believe this was fixed in 2.5.1 The main advantge of using the shell built-ins is they accurately track piped commands, the /usr/bin ones don't under all circumstances, throwin a couple of redirects, pipes and tees and they soon start getting baffled. Now if you take the command line and place it in a script and then the time the script using /usr/bin/time? thats a different matter. The high-res timer code that all the time commands use are divided into two distinct parts. The first part is the generic service that provides support for the processess that have set the interval timers with the real time clock (ITIMER_REAL), this will always decrement the timer structures on every occurence of the hardware clock interrupt, there are no exceptions. The second part operates on the processes, again it uses the hardware clock interrupt but this time will only decrements timers for currently running processes. The flexibility of the the service allows the timer to decrement in either user-mode only, the ITIMER_VIRTUAL setting or in both user and kernel mode (ITIMER_PROF). It is the later that is generally used for process time monitoring. The problem here is that the process must be able to restart uncompleted system calls since the timer can expire while in the process is executing in kernel mode. There are several circular linked lists to maintain the timers. The ITIMER_REAL ones are maintained in the global list, whereas the rest are maintained via the proc structure. There are an additional two variable maintained in the user structure which are incremented depending on the ITIMER setting. It is the failure to increment the timer structures when running the /usr/bin/time? for complex command lines that causes the problem and leads to inaccurate results. Paul Watson # WFSoftware Ltd # Writing a Datablade is like Tel: +44 1436 674729 # trying to find the square Fax: +44 1436 678693 # root of pi using roman numerals www.wfsoftware.com/informix #