DEV Community: Jakub Kwaśniewski

Hacking IDisposable: The Stopwatch Example

Jakub Kwaśniewski — Sun, 20 Feb 2022 22:20:35 +0000

Provides a mechanism for releasing unmanaged resources.

This is the first sentence you can read about IDisposable interface in the Microsoft documentation - and it definitely should be the primary usage of it. However, the C# language is cool enough to have a special using statement that comes along when using objects that implement IDisposable. There is something elegant and compact about this language structure, which makes me really like it - that's why I use it even for places that it was not designed for. Like, for example, wrapping up the Stopwatch.

Stopwatch

The Stopwatch class was introduced in .NET Framework 2.0 and since then became a de facto standard for measuring code execution time. If you were ever interested in checking how long does it takes to run a specific part of your program, you've probably stumbled into it.

The basic usage pattern of a Stopwatch class is as follows:

var stopwatch = new Stopwatch();
stopwatch.Start();

// Code which execution time we want to measure

stopwatch.Stop();
Console.WriteLine(stopwatch.Elapsed);

There are a couple of caveats - static method Stopwatch.StartNew() can be used as a shortcut for creating Stopwatch instance and starting it at the same time. Also, the Elapsed property can be accessed without actually stopping the stopwatch first - it will keep on counting time.

So the structure is already there - we start the stopwatch, we execute the code we want to measure, we stop the stopwatch. Whenever and wherever you do it, the structure always looks similar to this. And since it's as simple as wrapping the "proper" code you want to measure with some init and teardown actions, the using statement might be a good fit.

Disposable stopwatch

So lets start with defining a class implementing IDisposable.

public class Timer : IDisposable
{
    private readonly Stopwatch _stopwatch;

    public Timer()
    {
        _stopwatch = Stopwatch.StartNew();
    }

    public void Dispose()
    {
        _stopwatch.Stop();
        Console.WriteLine(_stopwatch.Elapsed);
    }
}

// Usage example

using (new Timer())
{
    // Code which execution time we want to measure
}

This is functionally identical to the previous example and for me looks better already, however there are a couple of things we can do to make it more useful.

First of all, writing to the console output is not necessarily the only thing we want to do with the measured time span. Sometimes it might be, but sometimes we'd rather write it to file or to an external system, eventually ending up in some kind of monitoring platform.

So we could parametrize the Timer and allow its clients to decide what to do with the measured execution time.

public class Timer : IDisposable
{
    private readonly Action<TimeSpan> _afterMeasuredAction;
    private readonly Stopwatch _stopwatch;

    public Timer(Action<TimeSpan> afterMeasuredAction)
    {
        _afterMeasuredAction = afterMeasuredAction ?? (_ => { });
        _stopwatch = Stopwatch.StartNew();
    }

    public void Dispose()
    {
        _stopwatch.Stop();
        _afterMeasuredAction.Invoke(_stopwatch.Elapsed);
    }
}

// Usage example

using (new Timer(measuredTime => Console.WriteLine(measuredTime)))
{
    // Code which execution time we want to measure
}

There's something I still don't like about this usage pattern. Maybe because we're newing up an object here that we don't really care about - not even assigning it to any variable. Effectively there's nothing wrong about it, cause what we really want is to create it and dispose automatically at the end of the using block. But if we don't need to do any other thing with this object - why do we need to know its type? Well, we don't - knowing that it implements IDisposable should be more than enough for us. So instead of newing up an instance of a specific type, I'd rather hide it with some method and directly return just an IDisposable.

public class Measurement
{
    public static IDisposable Run(
        Action<TimeSpan> afterMeasuredAction = null) =>
            new Timer(afterMeasuredAction);

    private class Timer : IDisposable
    {
        private readonly Action<TimeSpan> _afterMeasuredAction;
        private readonly Stopwatch _stopwatch;

        public Timer(Action<TimeSpan> afterMeasuredAction)
        {
            _afterMeasuredAction = afterMeasuredAction ?? (_ => { });
            _stopwatch = Stopwatch.StartNew();
        }

        public void Dispose()
        {
            _stopwatch.Stop();
            _afterMeasuredAction.Invoke(_stopwatch.Elapsed);
        }
    }
}

// Usage example

using (Measurement.Run(measuredTime => Console.WriteLine(measuredTime))
{
    // Code which execution time we want to measure
}

One last thing I'd like to enhance a bit. Since Measurement is a very generic purpose class - probably for use in many places, as we usually want to measure execution time of multiple methods or algorithms within our code base - we'd normally define this action after measure (like Console.WriteLine) many times. To avoid that we can create a specific class that uses the generic one.

public class LogMeasurement
{
    private readonly ILogger<LogMeasurement> _logger;

    public LogMeasurement(ILogger<LogMeasurement> logger)
    {
        _logger = logger;
    }

    public IDisposable Run() => Measurement.Run(
        timeSpan => _logger.LogTrace($"Measured time: {timeSpan}"));
}

// Usage example

using (_logMeasurement.Run())
{
    // Code which execution time we want to measure
}

Note that this time we have an instance Run() method instead of a static one as previously. The reason is that I'd probably want to inject this class in all the places I'd like to use it, so it's ready for usage in a dependency injection scenario. That's also why it has a constructor with its own dependencies injected. In other words we now have one class to gather everything needed to do whatever we want to do in our system with measured code execution time.

And if you sometimes want to do something else with it - you just define another similar class, which uses Measurement.Run with a different action, and inject it instead of the LogMeasurement one!

Post Scriptum

This blog post is mostly about answering the "How to measure code execution time?" question. One thing I haven't and won't dig too deep into is an answer to "Where to measure it?" question. But just briefly - I do think that any code not related strictly to the domain of the class or method just adds noise and distraction. So adding some logging, monitoring or execution time measuring logic in-place with the domain code is not necessarily the best idea. I'd rather extract it to some kind of decorator class instead.

Also, sorry for the clickbaitish title - the provided example is not really hacking the interface in any way. But it can be considered a usage outside of the definition mentioned at the very beginning, so in this sense what we're really doing is exploring the undocumented ways of using it. Sounds hacky enough for me!

Just code

Hacking IDisposable: The Stopwatch Example on GitHub + Tests

Why is programming hard?

Jakub Kwaśniewski — Sat, 29 May 2021 23:56:03 +0000

The software engineer

Why are you here? This one should be pretty obvious - it's a DEV community website, so you are here probably because you are a software engineer, right? At least that's why I am here! But lets go a bit deeper - maybe not all five whys deep, but at least one for now. Why are you a software engineer?

Now that question might already be answered in a number of ways. You might have well-established reasons to start coding, but sometimes it's not that sophisticated. I went to college to study IT without writing a single line of code before that happened. I definitely was not a geek, but I was pretty good at math in high school, and good result on a math exam was enough to start studying IT, so I went that route. But to keep things simple and quite technical at this point - we are developers today, because we became developers in the past and didn't quit so far.

This is quite interesting if you think of it - do you know any people that actually quit? I know a lot of developers that became ones after switching from a completely different business into IT, starting their careers as testers or customer support, becoming developers after couple of years. I know some developers that went into different roles within IT industry - scrum masters, project managers, sometimes testers, though generally the switch in the other direction seems to be more frequent. But it's quite rare to see people quitting IT to do something else.

I know a few people though, that plan to quit at some point. These are usually folks which are at their current position to earn enough money to start doing the thing they are really passionate about. It doesn't mean they aren't passionate about software engineering - although that also happens - but they just have bigger passions.

But in general the big picture from my point of view is that there is a lot of migration into IT, a lot of inside IT and pretty little out from IT. With more and more people needed, more positions being opened and good wages on average, I think it's a safe thing to say, that being a software engineer nowadays is a pretty comfortable occupation. This however does not mean that the job itself is easy to do.

Engineering the software

Because I think it really is not that easy. First of all, a software engineer has a lot of stuff to do. It's not only about writing code. It's designing, planning, estimating, writing documentation, discussing in meetings, preparing presentations etc., not even mentioning all the soft skills valuable when working in a team. Not all of these activities are something, that people with technical knowledge, after studying computer science, are the best in or feel most comfortable with. To be honest, the variety of these activities makes it really hard to find people which excel in all of them.

But that's not the most important thing. The responsibilities of a software engineer vary from company to company, or even from team to team, but still the main thing we do is writing code. So, as said above, it's not only about writing code, but it's still the most important activity - if you take out writing code from the list of activities a software engineer does, it's not a software engineer job description anymore!

And quite similarly, writing code is not an "atomic operation" as well - meaning that there are some aspects of writing code, that people might be better or worse at. The code we write should work and should be readable, to make it easy for the next person that comes to change it. And these two things need different mindset - while writing stuff that works is the domain of people with engineering skills, writing stuff that's readable is usually something in the toolset of the more humanities-minded people.

As developers we need to join these two abilities, to be good at what we do. We need to solve problems according to sometimes complex specifications, while implementing it in an easy to understand way. If it'd be easy, the specification would be written like that as well. It's not always easy to find good abstractions - the ones that will seem so logical for the reader, that he wouldn't even notice this design work someone put here, and the ones that he will flawlessly follow. It's not always easy to find good names - the ones that will fit so good, that it'll be obvious for the reader, what he's reading about. Actually, I'd say these things most of the time are really hard!

So it's not always easy to make it work and it's even harder to make it easy to rework. There are different abilities needed for both of these. I see this everyday - including myself - people good at one thing, but struggle with the other. That's why I think people with so many backgrounds - even if they didn't study IT or didn't do any other technical studies - can become pretty decent software engineers. But that's why I also think programming is hard, or at least it's hard to do it the right way.

Post Scriptum

This is my opening blog post, therefore I wanted to keep it more general, introductory. No worries, things will get more technical in the next ones. Although definitely from time to time I plan to write something similar to this one - lets call it an editorial - because writing about code without code is also possible.