UTC now!

The other day, I stumbled across this post, describing how .NET developers are alledgedly misuing DateTime.Now. The gist of it is that we are using DateTime.Now in cases where DateTime.UtcNow would be more appropriate, for instance when measuring runtime performance. The difference between Now and UtcNow is that the former gives you local time, whereas the latter gives you “universal” or location-independent time. It turns out that Now is one or two orders of magnitude slower than UtcNow; the reason being that Now has to derive the local time by calculating an offset from universal time depending on locale. Clearly, this is unnecessary work if all you’re going to do is calculate the time elapsed between two points in time. Based on this, the author of the blog post argues that using Now when you could have used UtcNow is wrong.

I’m of two minds about this issue. My gut reaction was that, “gee, that’s really unimportant”. Or to borrow a phrase from one of my co-workers, “I would look for performance optimisations elsewhere”. So Now is much slower than UtcNow. I didn’t know that, but then again I don’t think it’s a big deal. Performance doesn’t matter until it does – that is, when something is perceived as unacceptably slow by a user. Of course, the post includes the mandatory contrived example, showing how the difference between Now and UtcNow matters when current time is sampled a million times in a tight loop. Yup. EVERYTHING matters when you’re doing it a million times. (Especially if you do it on some thread where there’s a user waiting in the other end.) Nevertheless, I find it entirely plausible that in a practical scenario, there would be other things you needed to do a million times besides getting the time, which just might dwarf the demonstrated performance difference. Put it another way: I estimate there’s something like a one-in-a-million chance that you’re actually going to be in a real world situation where this is going to be a problem. Now for that one guy in Duluth, Minnesota who actually has to get the current time – and nothing else – a million consecutively for some business critical routine, it’s going to matter if he knows about the performance difference between Now and UtcNow. I hope he does. For the rest of us, not so much.

On the flip side though: now that I know, I’ll never again use Now if I can use UtcNow instead. Isn’t that ironic? I’ve just claimed that this has no practical implications whatsoever, and yet: In the future, whenever I’m doing some relative measurement of time, it’s UtcNow all the way. Unless it’s StopWatch, which is usually much more convenient (and uses UtcNow under the hood by default). After all, there’s no reason to waste clock cycles on purpose. Heh.

Lurking underneath this rather trivial matter, though, is a somewhat deeper issue. Which is: should I have known?

Isn’t it negligence on my part that I was unaware of the performance implications of using Now instead of UtcNow? After all, I’m a professional developer, right? I’ve heard Uncle Bob‘s sermons about craftmanship and I’m a believer. My employer pays me good money each month to produce the best code I’m able to. In turn, my employer’s customers rely on the quality of that code. And I’ve put my share of Now‘s in there, you know? Without needing to. Superflous work. Burnt cycles. UtcNow would have been just fine. Not that it matters, performance-wise, in any way, shape or form – if and when I’ve written sluggish code, it’s not because of Now – it’s because I’ve chosen a suboptimal algorithm or data structure at some key point in the application. Still: the right thing would have been to use UtcNow unless I needed local time, dammit! And I’ve plunged ahead, unwittingly using Now instead, all due to my incomplete knowledge of the .NET framework. Isn’t that sloppy?

As you can imagine, I’m totally going to exonerate myself on this issue. No, I should not have known! I mean, I could have known, it would have been nice if I would have known, but I don’t think I should have known. You see, programmers work in a constant state of partial, incomplete understanding. This is not an anomaly, it’s the name of the game. Modern software is just too large and complex to make it feasible to grok it all unless you’re L. Peter Deutsch or something. And you probably aren’t. This certainly goes for the vast .NET framework. According to this post, version 3.5 of the .NET framework contained 11417 types and 109657 members. Complete understanding is not only unattainable, it’s also economically unsound to aim for. Since program understanding is a slow and costly process, your efforts should be focussed on understanding what is needed to solve the problem at hand. You need just enough program understanding to implement a feature or fix a bug or whatever you need to do. Just-in-time program understanding is a lean and pragmatic approach that allows you to get things done. (Note that I’m not advocating programming by coincidence here. Clearly you have to understand, at some level, what the code you’re invoking does. But you do so at the appropriate level of abstraction. You shouldn’t have to fire up Reflector every time you’re using an API function.)

If anything, it’s an API design issue. (Blaming it on Microsoft is always a safe bet!) When using an API, you try to map the problem you need solved onto the members of the API. You scan the available properties and methods, and conjecture a hypothesis regarding which one will fulfill your need. In doing so, you reach for the simplest-sounding potential match first. Only when that doesn’t work for you do you consider the next most plausible candidate. You can think of this as API affordance – the API will invite you, through it’s vocabulary, to try out certain things first. If you need Foo to happen and the API supports methods Foo() and FrobnitzFoo(), you’re going to try Foo() first. Right? Only when the plain Foo() fails to Foo as you’d like it to will you try FrobnitzFoo() instead. I’m sure you can see the parallel to Now/UtcNow. Since Microsoft gave the straight-forward simplest name to the property that gives you local time, that’s what developers reach for, even when they just need a relative timestamp. It’s pure economics. And lo and behold! it works, because for all but the poor schmuck in Duluth, Now gets the job done just fine. The hypothesis is never falsified. (Of course, that guy from Duluth is going to end up an enlightened schmuck, because for him, the hypothesis will be falsified – he’s going to get burned by the relatively slow implementation, probe around the DateTime API, maybe even crank out Reflector, and eventually find that “hey, I should be using UtcNow instead”. And he’ll be good to go, and all smug about it to boot.)

Of course, we can speculate as to why Microsoft used the name ‘Now‘ instead of something like ‘LocalNow‘, which would have been more precise. Is it accidental? Due to negligence or incompetence? Probably not. Now is broadly applicable and good enough in all but the most extreme scenarios. It can be used successfully both for showing local time to the user (which is usually the right thing to do), and for measuring runtime performance (even though it’s not the optimal choice in the latter case). I think they did it very deliberately. And I don’t think it’s a bad thing. If Microsoft made a mistake, it’s that Now is a property. In general, the rule is that properties should be instantenous. According to the MSDN documentation, a method is preferable to a property when “[it] performs a time-consuming operation, [that is] perceivably slower than the time it takes to set or get a field’s value”. Arguably, then, Now should really have been Now(). That would have provided a subtle hint that getting the current time isn’t free. And these long posts about DateTime.Now wouldn’t have been written at all.

The Indispensable IDisposable

The using statement in C# is a peculiar spoonful of syntactic sugar. It is peculiar because it’s tailor-made for a particular interface in the .NET framework. (i.e. IDisposable). Hence in the C# standard, you’ll find that the semantics of using is defined in terms of how it interacts with that interface, the existence of which is sort of assumed a priori. So the boundary between language and library gets really blurred.

As you well know, the purpose of using is to make it 1) more convenient for programmers to work with so-called unmanaged resources, and 2) more likely that programmers will dispose of such resources in a timely manner. That’s why it’s there.

The archetypical usage is something like:

This will expand to:

The using statement has a lot of potential use cases beyond that, though – indeed, that’s what this blog post is all about! The MSDN documentation states that “the primary use of IDisposable is to release unmanaged resources”, but it is easy and fun to come up with interesting secondary uses. Basically any time you need something to happen before and after an operation, you got a potential use case for using. In other words, you can use it as sort of a poor man’s AOP.

Some people find the secondary uses for using to be abuse, others find it artistic. The most convincing argument I’ve read against liberal use of using is Eric Lippert’s comment on this stack overflow question. Essentially, the argument is that a Dispose method should be called out of politeness, not necessity: the correctness of your code shouldn’t depend upon Dispose being called. I won’t let that stop me though! (Granted, you’d need to put 1024 me’s in a cluster to get the brain equivalent of a Lippert, but hey – he’s just this guy, you know?). After all, what does code correctness mean? If your application leaks scarce resources due to untimely disposal, it’s broken – you’ll find it necessary to explicitly dispose of them. There’s a sliding scale between politeness and necessity, between art and abuse, and it’s not always obvious when you’re crossing the line. Also, I have to admit, I have a soft spot for cute solutions, especially when it makes for clean, readable code. I therefore lean towards the forgiving side. YMMW.

So with that out of the way, let’s start abusing using:

Example 1: Performance timing

In my mind, the simplest non-standard application of using is to measure the time spent doing some operation (typically a method call). A PerfTimer implementing IDisposible gives you a neat syntax for that:

Note that you don’t have to hold on to the PerfTimer you obtain in the using statement, since you’re not actually using it inside the scope of the using block. Obviously Dispose will be called nevertheless.

Example 2: Impersonation

Impersonation is one of my favorite using use cases. What you want is to carry out a sequence of instructions using a particular identity, and then revert to the original identity when you’re done. Wrapping your fake id up in an IDisposable makes it all very clean and readable:

Example 3: Temporary dependency replacement

Another useful application of using is to fake out some global resource during testing. It’s really a kind of dependency injection happening in the using statement. The neat thing is that you can reinject the real object when you’re done. This can help avoid side-effects from one test affecting another test.

Let’s say you want to control time:

The idea is that we eliminate uses of DateTime.Now in our code, and consistently use Timepiece.Now instead. By default, Timepiece.Now uses DateTime.Now to yield the current time, but you’re free to replace it. You can pass in your own time provider to the Replacement method, and that we be used instead – until someone calls Dispose on the TempTimepiece instance returned from Replacement, that is. In the code above, we’re causing time to go backwards for the three Ticks inside the using block. The output looks like this:

Example 4: Printing nested structures

So far we’ve seen some modest examples of abuse. For our last example, let’s go a bit overboard, forget our inhibitions and really embrace using!

Here’s what I mean:

Hee hee.

Yup, it’s an embedded DSL for writing HTML, based on the using statement. Whatever your other reactions might be – it’s fairly readable, don’t you think?

When you run it, it produces the following output (nicely formatted and everything):

How does it work, though?

Well, the basic idea is that you don’t really have to obtain a new IDisposable every time you’re using using. You can keep using the same one over and over, altering its state as you go along. Here’s how you can do it:

So you can see, it’s almost like you’re using an IDisposable in a fluent interface. You just keep using the same DisposableWriter over and over again! Internally, it maintains a stack of tags. Whenever you add a new tag to the writer (which happens on each new using), it writes the start tag to the stream and pushes it onto the stack. When the using block ends, Dispose is called on the DisposableWriter – causing it to pop the correct tag off the stack and write the corresponding end tag to the stream. The indentation is determined by the depth of the stack, of course.

Wasn’t that fun? There are other things you could do, too. For instance, I bet you could implement an interpreter for a stack-based language (such as IL) pretty easily. Let each instruction implement IDisposable, pop values off the stack upon instantiation, execute the instruction, optionally push a value back on upon Dispose. Shouldn’t be hard at all.

Now if I could only come up with some neat abuses of foreach…