优化DateTime.Now的替代方案
我和一位同事在这个问题上来回走动，我希望得到一些外界意见，看看我提出的解决方案是否是一个好主意。
首先，免责声明：我意识到“优化DateTime.Now ”的概念对你们中的某些人来说听起来很疯狂。 我有几个先发制人的防御措施：
- 我有时会怀疑那些总是说“计算机速度快;可读性总是在优化之前”的人经常会从开发应用程序的经验中说出，虽然这些应用程序可能很重要但性能并不重要 。 我说的是要尽可能接近瞬间发生事情 – 比如，在几纳秒内（在某些行业中，这很重要 – 例如，实时高频交易）。
- 即使考虑到这一点，我在下面描述的替代方法实际上是非常易读的。 这不是一个奇怪的黑客，只是一个可靠而快速工作的简单方法。
- 我们有跑步测试。
DateTime.Now很慢（相对来说）。 下面的方法更快。
现在，问题本身。
基本上，通过测试，我们发现DateTime.Now大约需要25个滴答（大约2.5微秒）才能运行。 当然，这是平均数千到数百万次通话的平均值。 看起来第一个呼叫实际上需要花费大量时间，后续呼叫要快得多。 但仍然是25个蜱是平均值。
然而，我和我的同事注意到DateTime.UtcNow运行的时间要少得多 – 平均只有0.03微秒。
鉴于我们的应用程序永远不会在夏令时发生变化时运行 ，我的建议是创建以下类：
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); } }
换句话说，在启动时确定本地时区的UTC偏移量，并从该点开始利用DateTime.UtcNow速度通过FastDateTime.Now更快地获得当前时间。
如果在应用程序运行期间UTC偏移量发生变化（例如，应用程序在一夜之间运行），我可以看到这是一个问题; 但正如我已经说过的那样，在我们的情况下，这不会发生。
我的同事对如何做到这一点有不同的想法，这对我来说有点过于复杂。 最终， 据我所知 ，我们的两种方法都返回了准确的结果，我的方法稍快一些（约0.07微秒与~0.21微秒）。
我想知道的是：
- 我在这里错过了什么吗？ 鉴于上述事实，应用程序将只在一个日期的时间范围内运行，
FastDateTime.Now安全吗？ - 任何人都可以想到更快的方式获得当前时间吗？
你能使用DateTime.UtcNow，只在数据出现时转换为本地时间吗？ 您已经确定DateTime.UtcNow更快，它将消除DST周围的任何歧义。
结果之一的一个区别
DateTime.Now
和
DateTime.UtcNow + LocalUtcOffset
是Kind属性的值 – Local vs Utc。 如果将生成的DateTime传递给第三方库，请考虑返回
DateTime.SpecifyKind(DateTime.UtcNow + LocalUtcOffset, DateTimeKind.Local)
我喜欢你的解决方案。 我做了一些测试，看看它与常规DateTime.Now相比有多快
DateTime.UtcNow比DateTime.Now快117倍
如果我们只关注持续时间而不是时间本身，那么使用DateTime.UtcNow就足够了。 如果我们只需要计算特定代码段的duration= End_time - Start_time （执行duration= End_time - Start_time ），那么时区并不重要， DateTime.UtcNow就足够了。
但是如果我们需要时间本身，那么我们需要做DateTime.UtcNow + LocalUtcOffset
只是添加时间跨度减慢了一点点，现在根据我的测试，我们只比常规DateTime.Now快49倍。现在
如果我们按照建议将这个计算放在一个单独的函数/类中，那么调用该方法会使我们更慢，我们只会快34倍。
但即便快了34倍！
简而言之，使用DateTime.UtcNow比DateTime.Now快得多
我发现改进建议类的唯一方法是使用内联代码： DateTime.UtcNow + LocalUtcOffset而不是调用类方法
BTW试图强制编译器通过使用[MethodImpl(MethodImplOptions.AggressiveInlining)]内联编译似乎没有加快速度。
以相反的顺序回答：
2）我想不出更快的方式。
1）值得检查管道中是否有任何框架改进，就像他们刚刚宣布的System.IO一样
很难确定安全性，但这是很多unit testing的问题。 想到夏令时。 系统一显然是非常强硬的，而你的系统却没有。