优化替代DateTime.Now [英] Optimizing alternatives to DateTime.Now

问题描述

一个同事和我来回在这个问题上，我希望能得到一些外界意见，我提出的解决方案是否是一个好主意。

首先，声明：我认识到优化 DateTime.Now 的概念听起来很疯狂到一些你。我有一对夫妇先发制人的防御：

1. 我有时怀疑，这些人谁总是说，计算机快;可读性的总是的来优化前往往从经验上讲开发应用程序在性能，尽管它可能是的重要的，是不是关键。我说的是需要的事情发生接近即时地 - 样，纳秒（在某些行业，这的确实的事情 - 例如，实时高频交易）。


2. 即使考虑到这一点，在另一种方法我下面介绍的就是，其实相当的可读性。这不是一个奇怪的黑客，仅仅是可靠和快速的工作的简单方法。


3. 我们的包含运行测试。 DateTime.Now 是慢（相对而言）。下面的方法的是更快。

现在，到问题本身。

基本上，从测试中，我们发现， DateTime.Now 大致需要25蜱（约2.5微秒）来运行。这是场均出过数千至数百万的电话，当然。似乎第一呼叫实际花费的时间显著量和随后调用是快得多。但尽管如此，25蜱是平均。

不过，我的同事和我注意到 DateTime.UtcNow 大幅取更少的时间来运行 - 平均仅为0.03微秒

的鉴于我们的应用程序将永远不会被运行时有夏令时<变更/ em>的，我的建议是创建下面的类：

 公共静态类FastDateTime {
公共静态时间跨度LocalUtcOffset {搞定;私人集; } 
 
公共静态的DateTime现在{
 {返回DateTime.UtcNow + LocalUtcOffset; } 
} 
 
静态FastDateTime（）{
 LocalUtcOffset = TimeZone.CurrentTimeZone.GetUtcOffset（DateTime.Now）; 
} 
} 
  

在换句话说，确定与UTC为本地偏移时区的一次 - 在启动 - 并从该点开始利用 DateTime.UtcNow 的速度来获得当前的时间快了很多通过 FastDateTime.Now 。

我可以看到这是一个问题，如果UTC在应用程序正在运行时间偏移改变（如果，例如，该应用程序被过夜运行）;但正如我说已经在的我们的情况下，这不会发生。

我的同事有关于如何做一个不同的想法，是不是有点太参与，我在这里解释。最终，的据我可以告诉的，既有我们的方法返回一个准确的结果，我的速度稍快为（0.07〜主场迎战微秒〜0.21微秒）。

我想知道的是：

1. 我失去了一些东西在这里？鉴于上述事实，即应用程序将只有一个日期的时间框架内运行，为 FastDateTime.Now 安全吗？


2. 可以别人或许认为获取当前时间的甚至的更快的办法吗？

解决方案

您可以只使用DateTime.UtcNow，并且只显示的数据时转换为本地时间？你已经确定DateTime.UtcNow是更快，它会删除DST周围任何含糊之处。

A colleague and I are going back and forth on this issue and I'm hoping to get some outside opinions as to whether or not my proposed solution is a good idea.

First, a disclaimer: I realize that the notion of "optimizing DateTime.Now" sounds crazy to some of you. I have a couple of pre-emptive defenses:

1. I sometimes suspect that those people who always say, "Computers are fast; readability always comes before optimization" are often speaking from experience developing applications where performance, though it may be important, is not critical. I'm talking about needing things to happen as close to instantaneously as possible -- like, within nanoseconds (in certain industries, this does matter -- for instance, real-time high-frequency trading).
2. Even with that in mind, the alternative approach I describe below is, in fact, quite readable. It is not a bizarre hack, just a simple method that works reliably and fast.
3. We have runs tests. DateTime.Now is slow (relatively speaking). The method below is faster.

Now, onto the question itself.

Basically, from tests, we've found that DateTime.Now takes roughly 25 ticks (around 2.5 microseconds) to run. This is averaged out over thousands to millions of calls, of course. It appears that the first call actually takes a significant amount of time and subsequent calls are much faster. But still, 25 ticks is the average.

However, my colleague and I noticed that DateTime.UtcNow takes substantially less time to run -- on average, a mere 0.03 microseconds.

Given that our application will never be running while there is a change in Daylight Savings Time, my suggestion was to create the following class:

public static class FastDateTime {
    public static TimeSpan LocalUtcOffset { get; private set; }

    public static DateTime Now {
        get { return DateTime.UtcNow + LocalUtcOffset; }
    }

    static FastDateTime() {
        LocalUtcOffset = TimeZone.CurrentTimeZone.GetUtcOffset(DateTime.Now);
    }
}

In other words, determine the UTC offset for the local timezone once -- at startup -- and from that point onward leverage the speed of DateTime.UtcNow to get the current time a lot faster via FastDateTime.Now.

I could see this being a problem if the UTC offset changed during the time the application was running (if, for example, the application was running overnight); but as I stated already, in our case, that will not happen.

My colleague has a different idea about how to do it, which is a bit too involved for me to explain here. Ultimately, as far as I can tell, both of our approaches return an accurate result, mine being slightly faster (~0.07 microseconds vs. ~0.21 microseconds).

What I want to know is:

1. Am I missing something here? Given the abovementioned fact that the application will only run within the time frame of a single date, is FastDateTime.Now safe?
2. Can anyone else perhaps think of an even faster way of getting the current time?

解决方案

Could you just use DateTime.UtcNow, and only convert to local time when the data is presented? You've already determined that DateTime.UtcNow is much faster and it will remove any ambiguity around DST.

这篇关于优化替代DateTime.Now的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！