I am a programmer and architect (the kind that writes code) with a focus on testing and open source; I maintain the PHPUnit_Selenium project. I believe programming is one of the hardest and most beautiful jobs in the world. Giorgio is a DZone MVB and is not an employee of DZone and has posted 636 posts at DZone. You can read more from them at their website. View Full User Profile

The Wheel: Symfony Stopwatch

05.01.2013
| 3590 views |
  • submit to reddit

It's impossible to predict performance and you need the right tooling to measure it. The Stopwatch Symfony Component is a userland object that lets you time critical section of code to get some data about their execution, even directly in the production environment.

The previous episodes of The Wheel:

The API

A Stopwatch is an object that measures time, and that you can start and stop at will to focus the measuremente only on interesting parts of the code. Basically, the Stopwatch is a form of automated logging that marks the start and stop of a section with timestamps, calculating the difference between them.

Here is a base test from the suite of the component:

  $stopwatch = new Stopwatch();
  $stopwatch->start('foo', 'cat');
  usleep(20000);
  $event = $stopwatch->stop('foo');

  $this->assertInstanceof('Symfony\Component\Stopwatch\StopwatchEvent', $event);
  $total = $event->getDuration(); // about 20


The Stopwatch can also divide the measurement into sections, so that you only need one Stopwatch object even for multiple measurements:

  $stopwatch->openSection();
  $stopwatch->start('foo', 'cat');
  $stopwatch->stop('foo');
  $stopwatch->start('bar', 'cat');
  $stopwatch->stop('bar');
  $stopwatch->stopSection('1');

Since typically stopwatches are objects that are introduced into the code when there is a performance problem and discarded thereafter, I have no problem into putting a Stopwatch instance in a global or static variable, and log its results at the end of the process. Having a single instance that can work with multiple intervals simplifies this process.

The pros

The functionality of the Stopwatch is very basic, but lets you profile your code tentatively in production, where you usually cannot install Xdebug or other tools that produce a cachegrind result due to their weight.

The Stopwatch is only a composer.json line away, and we're talking about 4 classes in total: its installation into your project shouldn't raise concerns. We have to resist the urge to code up a Stopwatch class ourselves when the need for it manifests. :)

The cons

The only problem I see with the Symfony Stopwatch is its limited functionality: you'll have to build a new Stopwatch or extend this one (or another library) to get some other feature, such as the ability to see a section as a single event. It's mostly useful in loops:

foreach ($bigArray as $i => $value) {
  // stuff
  $stopwatch->openSection('critical');
  $stopwatch->start($i, 'description');
  // critical section
  $stopwatch->stopSection('critical');
  // other stuff
}

The API exposes the events as separate object, so currently you have to sum them up yourself. I'm not sure the vision of this component would accomodate these extensions, but we can always make a pull request.

The Stopwatch also do not expose time measurements with a microsecond-based precision, but you probably shouldn't use PHP if you're needing this fine tuning for your code.

Published at DZone with permission of Giorgio Sironi, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)