For the second point, you better read the original paper rather than 2-3 lines of it. That paper is a very old one in GO TO days with a different focus. Unfortunately, programmers just extract some quotes without knowing the context or anything. I’ve read that paper (again, because it is my daily job and my field of specialty to work on compilers) and that’s why I could give you the real point of what he says even though the concept of premature optimization is beyond him and his paper and it seems that it’s all you know about premature optimization! If you even read those few lines carefully and with an open mind, you understand the point. Anyways, the whole point about using UtcNow vs. Now is not an optimization and you still don’t get it. It is a practice. You need to write the code that way in the first place not that you are optimizing anything by writing it that way. Now is designed for a purpose as UtcNow is designed.

It’s like using a screwdriver to open your refrigerator, and then saying that I could open the door with no significant difference in time, so I’m doing it right. No, you’re doing it wrong because your wasting resources and may hurt your refrigerator in the long time.

If you think that you should program professionally without a deep understanding of your language, then it’s you being on the wrong track about the whole thing. Unfortunately, this is the case with many Microsoft developers!l DateTime is one of the core types of the .NET Framework being taught in the very first stages of learning. If you don’t know it very well, you’re not a good programmer.

I think I am done with this discussion. My reasons along with numbers and my original post are available to a reader and they can read and judge about the correctness of things if they have a good background in simple arithmetic mathematics. Almost one month after my original post and publishing it on some other prominent .NET communities being read by over 10000 visitors, you’re the first person coming up with such a reasoning and I’m really surprised. I’m more surprised when you try so hard to relate my post to profilers where it doesn’t have anything to do with it.

Incorrect. What I’m saying is that there are many so-called ‘performance issues’ in the average application like .Now vs .UtcNow, for vs foreach, hoisting, etc. that just aren’t worth worrying about until they become a problem.

> Addressing your second question, you’re definitely wrong about your understanding of premature optimisation.
> Using UtcNow doesn’t have any extra effort than Now. All you need is to press tab when you select it in intellisense, so you even don’t need to type extra words during programming.

Here’s my understanding of premature optimisation, a quote from Donald Knuth:

“Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.”

For me, the performance of .Now definitely falls into the 97% category. Also note the emphasis on debugging and maintenance, not the initial writing of the code.

> You have started with my original blog post trying to convince your reader that profilers are good. This doesn’t have anything to do with a profiler.

Not really. What I picked up in your blog post was that it stated that most programmers carelessly use frameworks they don’t fully understand. This is exactly why we have abstractions. If your position is that we must know how the entire class library is implemented before we write a line of code, I couldn’t disagree more.

Addressing your first question, your question is a direct result of the wrong understanding of the whole point of my original post. Why do you think that writing that blog post, I asserted that all performance issues in an application are for DateTime.Now? I talked about a wrong practice and suggested the good practice that should be followed. That simple. Unfortunately, you’re trying to make it look like that I’m saying that all the performance issues in an application are due to the wrong use of DateTime.Now and am suggesting that somebody should dig into DateTime types in his application for any performance issue.

Addressing your second question, you’re definitely wrong about your understanding of premature optimisation. Premature optimisation is not about ignoring little things or focusing on them. It’s about trying to optimise something small by changing the design of your software and spending a lot of effort in it, and essentially, spending more time on optimisation than what will be achieved with it . Unfortunately, you have a wrong understanding of this, too. Using UtcNow doesn’t have any extra effort than Now. All you need is to press tab when you select it in intellisense, so you even don’t need to type extra words during programming. The improvement gain is big enough that it outweighs no effort that you made in making it better, so it is not a premature optimisation.

And again, you better read more about the way profilers are designed. There is no magic being done by profilers that you think they can catch many of errors done by a software developer missing very basic points like what I mentioned in my post. They’re designed to detect special categories of bottlenecks especially those related to resource-intensive tasks. Now if you make terrible mistakes in your design, you shouldn’t expect them to save you.

All in all, your reasoning is very weak and senseless. You’re trying to relate things that don’t relate at all. You have started with my original blog post trying to convince your reader that profilers are good. This doesn’t have anything to do with a profiler. What I mentioned is a practice that should be followed regardless of using a profiler. Even if your application is doing great, you need to apply such practices to make it even better (if you’re a professional developer who cares about the quality of his code).

The bottom line is: 1- A practice is a practice that should be followed no matter what. 2- A profiler is not everything and can’t do everything. There are many things they can’t catch and you need to follow the best practices and learn your language and platform to avoid potential problems that can’t be caught by a profiler.

I’m not sure you can know that for sure without looking at the rest of the application. You have to optimise the whole application not just one piece of it because you happen to know that part of the framework. What I want to know is this:

Given an application that has performance problems and is littered with DateTime.Now calls everywhere, would you:

A) Immediately change all the .Now calls to .UtcNow?
or
B) Run a profiler against the application?

I would choose B because that will lead me to areas of the code that require the most attention.

> The thing is that premature optimization needs to affect your software design in a negative way and give you very little improvements, but this is not the case with our situation.

Premature optimisation has nothing to do with affecting your design (or your performance) in a negative way. It’s about optimisation of an existing design for negligible benefit. You may actually improve the performance of the application but not in a way that is perceivable by the user.

Many people tend to fall into the “premature optimisation” hole and often waste many hours optimising something that does not need to be optimised. Often the biggest speed savings come from changes to your code (less loops, cutting out wasteful if statements, less boxing and un-boxing etc)

I use a similar set of rules to you… although I tend to measure twice. Then pick off any “low hanging fruit” and then start looking into the more complicated things if needed. Like you say often its something simple like a extra web service call, or a missing index on a database table.

BTW Reflector is probably one of the most useful apps, use it a lot to reverse engineer SDK’s and workaround bugs in them.

Generally speaking, you need to know that premature optimization is hard to justify because it has a variance meaning based on the situation. For our situation I’d strongly disagree on that for the reasons mentioned above.

Even on this argument, who has said that it’s just 15 iterations? Why don’t you see that even one iteration of such a call may be called 10000 times in a small web application everyday? Multiply that in 30 and see how big it can become in a month. When you think about software, you need to think about a production software with its real demands not a small prototype with one method that you run once on your local machine. This is why you’ve mistaken the concept of profilers and think that they can help you avoid falling into many of such traps.

Unfortunately, you’re combining this wrong view with your emphasis on using profilers rather than your knowledge to conclude something that is totally wrong. Nothing is negligible in software especially in compilers and it is important to learn the best practices and apply them rather than ignoring them because they’re small (in this case they’re not definitely). Such a small change in a small web application in 1-2 years is large enough and it’s even more catastrophic if you’re running a bigger application. Even if you’re wasting only 15 minutes of your visitors’ time in 5 years (putting the hardware resources aside), you’re doing it wrong because you could avoid that. There is no hassle in using UtcNow rather than Now!

If you want to support profilers and they’re use, it’s good and I recommend that, but this is the wrong topic to use in order to promote them. They’re designed with a different structure that can’t catch everything for you.

The sum total of what I know about this application is contained in a single tweet. Based on that, I don’t think the difference in performance between DateTime.Now and DateTime.UtcNow is an issue. The way to convince me otherwise is by showing me the profiler output of the application indicating that it is bottleneck.

What I am saying is that when it comes to performance optimisation, profiling will lead you to what you need to know. Learning class library trivia will not.

If you’re saying that the use of DateTime.Now vs. DateTime.UtcNow is not a big deal, the answer is no, you’re wrong, because numbers are self-explanatory. If you’re saying that there are other bad practices cause bigger performance impacts, that’s an obvious thing and I never said this is the only one.