另一个“不重要”的性能问题。 不重要的,因为主要代码可读性比几毫秒更重要,但无论如何有趣。 我注意到不同DateTime比较之间存在差异。为什么Date1.CompareTo(Date2)> 0比Date1> Date2更快?
我检查3层的替代品:
Dim clock As New System.Diagnostics.Stopwatch
Dim t1, t2, t3 As Long
Dim Date1 As Date = Date.Now.AddSeconds(2), Date2 As Date = Date.Now
Dim isGreaterThan As Boolean
clock.Start()
For i As Int32 = 1 To 1000000000
isGreaterThan = Date1 > Date2
Next
clock.Stop()
t1 = clock.ElapsedMilliseconds
clock.Reset()
clock.Start()
For i As Int32 = 1 To 1000000000
isGreaterThan = Date.Compare(Date1, Date2) > 0
Next
clock.Stop()
t2 = clock.ElapsedMilliseconds
clock.Reset()
clock.Start()
For i As Int32 = 1 To 1000000000
isGreaterThan = Date1.CompareTo(Date2) > 0
Next
clock.Stop()
t3 = clock.ElapsedMilliseconds
结果:
- 日期1>日期2 = 13207/13251/13267/13569/13100 = 毫秒
- Date.Compare( Date1,Date2)> 0 = 13510/13194/13081/13353/13092 = ms
- Date1.CompareTo(Date2)> 0 = 11776/11768/11865/11776/11847 = 毫秒
通常我选择第一方法,因为它是更具有可读性和比其他故障安全。方法3是最快的。这是编译器在我使用运算符重载方法1时会选择的方法吗?如果是,为什么在运行时会有差异? 方法2是最慢的,也许是因为它是共享/静态的?! UPDATE:增加了一些更多的值。现在Metod 1和2相当快。
也许有人可以用事实来澄清它。 谢谢。
在10亿次迭代中,相差不到2秒......实际上并不重要,也不重要。 – Oded 2010-08-06 10:44:36
您是否测量过多次,排除异常值并对结果进行平均? – 2010-08-06 10:45:09
无论原因如何,“缓慢”版本每秒(在您的硬件上)的* 75百万*比较而不是* 85百万*。除非您在某个问题的基准测试中依赖于性能的应用程序处于紧缩环境中,否则更偏好于微观优化的可读性。 – 2010-08-06 10:57:20