优化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的问题。 想到夏令时。 系统一显然是非常强硬的,而你的系统却没有。
上述就是C#学习教程:优化DateTime.Now的替代方案分享的全部内容,如果对大家有所用处且需要了解更多关于C#学习教程,希望大家多多关注—计算机技术网(www.ctvol.com)!
本文来自网络收集,不代表计算机技术网立场,如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址:https://www.ctvol.com/cdevelopment/950653.html