Tommaso Piazza

When writing software it always good practice to keep an eye on how much resources will be used by our code at run time.
Resources are for example time, memory, disks space, battery power etc. etc.

Measuring resource usage at run time is called Profiling. Specifically in this article I will be addressing Time Profiling.

If you work on Apple platforms you should be familiar with Instruments. The Time Profiler within Instruments is
at your disposal to help you analyze where your application is spending most of it’s cpu time and eliminate bottlenecks.

Instead I will present a quicker solution to answer the question: “How long will this take?”.
This solution can be used while developing (e.g. for sanity checks) or if you need a permanent log every time your code runs (e.g. in debug builds).

The basic functionality needed to time the execution of a certain piece of code is very similar to the one of a stop watch.

##Replicating a Stop Watch

A stop watch at it’s most basic functionality has the following interface:

Start Timer

Stop Timer

Some stop watches allow you to start an stop multiple timers, which translates to:

Start Timer for event

Stop Timer for event

That looks pretty simple and should be enough to help us answer our “How long will this take?” question.

However we can keep thing even more
simple, and avoid dealing with timers all together. We’re instead just going to log the start/stop time of an event.
This will be the base for our stop watch.

In code it will look as follows:

// Create an event and log the start timeStopWatch.starEvent("important function")performance_critical_function()// Get the event and log the stop timeStopWatch.stopEvent("important function")

A Stop Watch Event

Since we’re going to base our timing on measuring the difference between start/stop time of an event, it’s pretty clear that
we need to have at least 2 properties in our StopWatchEvent class.

A start time

A stop time

To be as accurate as possible, we’re going to get the time information expressed as time units in the system’s time reference frame.
On iOS we can simply use mach_absolute_time() to do so.

To these two properties we’re going to add a third one to know in what state a stop watch event is. This is the state of the
stop watch event.

A Stop Watch

Dealing with raw stop watch events would mean that we would have to keep a reference around for every event that we want to time. That is
going to be pretty inconvenient if what we want to profile starts in a certain part of our application and end in at a completely different
point in the code. Passing the reference of that particular event around is going to be annoying.

For this purpose we’re going to create a StopWatch class to store all the events. We’re also going to use this class to start and stop events
without having to create a StopWatchEvent directly.