Package net.sf.sensor.timer

This package provides support for measuring the time it takes for a piece of code to complete.

See:
Description

Class Summary

Timer	Short-lived, non thread-safe input frontend class for working with timers.
TimerRuntime	Main entry point for working with Timers and TimerStatistics.
TimerStatistics	Thread-safe, refreshable snapshot view to the internally managed TimerData representing the timing values as they were when the refresh() method was last called.

Package net.sf.sensor.timer Description

This package provides support for measuring the time it takes for a piece of code to complete.

Timers should preferably be applied to code using the various AOP methods provided by the Sensor AOP module (Spring interceptors, AspectJ aspects, etc.). Using manual (ie directly in the original source code) timing is pretty invasive and is not encouraged. But just in case, here is an example of how to do some basic timing:

  // ...
  // get a reference to the TimerRuntime class through dependency injection
  // or by using the static method in the StaticSensorRuntime support class.
  // ...
  
  public void someMethodThatNeedsToBeTimed() {
    // start a Timer
    // You can use any label as long as it is unique but it is recommened to
    // use the fully qualified name of the current class plus the name of the
    // method that is being timed. That way the chance of namespace conflicts
    // between labels is minimized.
    Timer timer = timerRuntime.startTimer(this.getClass().getName() + ".someMethodThatNeedsToBeTimed()");   
    
    // ...the code that need to be timed...
  
    timer.stop();
  }
    

To view the results, you can use one of the many reporting options offered by the Sensor Reporting module, including a log4j/commons-logging logger, a file dumper, a JMX MBean, a runtime web page, and the full Sensor Console web application, which offers database/file persistence and graphs showing performance over time.