Measurements and Timings Profiling Tools

- 22 - • Network packet sniffers both hardware and software types, e.g., netstat • Process and thread listing utilities top , ps on Unix; the task manager and performance monitor on Windows • System performance measuring utilities vmstat , iostat , sar , top on Unix; the task manager and performance monitor on Windows

2.1 Measurements and Timings

When looking at timings, be aware that different tools affect the performance of applications in different ways. Any profiler slows down the application it is profiling. The degree of slowdown can vary from a few percent to a few hundred percent. Using System.currentTimeMillis in the code to get timestamps is the only reliable way to determine the time taken by each part of the application. In addition, System.currentTimeMillis is quick and has no effect on application timing as long as you are not measuring too many intervals or ridiculously short intervals; see the discussion in Section 1.7 in Chapter 1 . Another variation on timing the application arises from the underlying operating system . The operating system can allocate different priorities for different processes, and these priorities determine the importance the operating system applies to a particular process. This in turn affects the amount of CPU time allocated to a particular process compared to other processes. Furthermore, these priorities can change over the lifetime of the process. It is usual for server operating systems to gradually decrease the priority of a process over that processs lifetime. This means that the process will have shorter periods of the CPU allocated to it before it is put back in the runnable queue. An adaptive VM like Suns HotSpot can give you the reverse situation, speeding up code shortly after it has started running see Section 3.3 . Whether or not a process runs in the foreground can also be important. For example, on a machine with the workstation version of Windows most varieties including NT, 95, 98, and 2000, foreground processes are given maximum priority. This ensures that the window currently being worked on is maximally responsive. However, if you start a test and then put it in the background so that you can do something else while it runs, the measured times can be very different from the results you would get if you left that test running in the foreground. This applies even if you do not actually do anything else while the test is running in the background. Similarly, on server machines, certain processes may be allocated maximum priority for example, Windows NT and 2000 server version, as well as most Unix server configured machines, allocate maximum priority to network IO processes. This means that to get pure absolute times, you need to run tests in the foreground on a machine with no other significant processes running, and use System.currentTimeMillis to measure the elapsed times. Any other configuration implies some overhead added to timings, and you must be aware of this. As long as you are aware of any extra overhead, you can usually determine whether any particular measurement is relevant or not. Most profiles provide useful relative timings, and you are usually better off ignoring the absolute times when looking at profile results. Be careful when comparing absolute times run under different conditions, e.g., with and without a profiler, in the foreground versus in the background, on a very lightly loaded server for example, in the evening compared to a moderately loaded one during the day. All these types of comparisons can be misleading. You also need to take into account cache effects . There will be effects from caches in the hardware, in the operating system, across various points in a network, and in the application. Starting the application for the first time on a newly booted system usually gives different timings as compared - 23 - to starting for the first time on a system that has been running for a while, and these both give different timings compared to an application that has been run several times previously on the system. All these variations need to be considered, and a consistent test scenario used. Typically, you need to manage the caches in the application, perhaps explicitly emptying or filling them, for each test run to get repeatable results. The other caches are difficult to manipulate, and you should try to approximate the targeted running environment as closely as possible, rather than test each possible variation in the environment.

2.2 Garbage Collection