为什么 Date1.CompareTo(Date2) > 0 比 Date1 快 >日期2?
另一个“不重要”的性能问题。 不重要,因为大多数代码可读性比几毫秒重要得多,但无论如何都很有趣。 我注意到不同的日期时间比较之间存在差异。
我检查了 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
结果:
- Date1 > Date2 = 13207/13251/13267/13569/13100 = 13279 ms
- Date.Compare(Date1, Date2) > 0 = 13510/13194/13081/13353/13092 = 13246 毫秒
- Date1.CompareTo(Date2) > 0 = 11776/11768/11865/11776/11847 = 11806 ms
通常我选择第一种方法,因为它比其他方法更具可读性和故障安全性。 方法3是最快的。这是当我使用运算符重载方法1时编译器会选择的方法吗?如果是的话,为什么运行时会有差异? 方法2是最慢的,可能是因为它是共享/静态的?! 更新:添加了更多值。现在方法 1 和方法 2 的速度相当快。
或许有人可以用事实来澄清。 谢谢。
Another "unimportant" performance question.
Unimportant because mostly code-readability is much more important than a few milliseconds, but interesting anyway.
I noticed that there are differences between different DateTime Comparisons.
I checked 3 alternatives:
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
The results:
- Date1 > Date2 = 13207/13251/13267/13569/13100 = 13279 ms
- Date.Compare(Date1, Date2) > 0 = 13510/13194/13081/13353/13092 = 13246 ms
- Date1.CompareTo(Date2) > 0 = 11776/11768/11865/11776/11847 = 11806 ms
Normally i choose first method because it is more readable and fail-safer than the others.
Method 3 is the fastest. Is this the method that the compiler would choose when i use the operator overloaded method 1? When yes, why are there differences during runtime?
Method 2 is the slowest, maybe because it is shared/static?!
UPDATE: added some more values. Now Metod 1 and 2 are pretty equal fast.
Perhaps somebody could clarify it with facts.
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
让我们在这个函数上使用一些 Reflector-Magic(全部来自 DateTime-Type):
Operator " > "
Compare
CompareTo
让我们把它分解一下:
Operator >
And
Compare 和 CompareTo
< code>CompareTo 很可能更快,因为它不需要访问
外部
对象,而是可以从自身提取变量之一。编辑:通过查看函数,我意识到
>
的性能应始终保持不变,而Compare
和的性能>CompareTo
基于传递的值:不过,我们正在谈论的性能增益或损失是......我该怎么说。 ..我一点也不在乎。 ;)但是这很有趣,我同意。
Let's use some Reflector-Magic on this functions (all from the DateTime-Type):
Operator " > "
Compare
CompareTo
Let's break it down:
Operator >
And
Compare and CompareTo
CompareTo
is most likely faster because it does not need to access anoutside
object, but can instead draw one of the variables from itself.Edit: From looking at the functions I realize that the performance of
>
should always stay the same, while the performance ofCompare
andCompareTo
are based on the passed values:Though, the performance gain or loss we're talking about is...how shall I say...I couldn't care less. ;) But it's quiet interesting, I agree.
如果这些数字持续存在,则可能存在某种缓存。要检测到这一点,您可以尝试重新排序程序中的测试或重复测试三元组(如 ABCABC)。
If the numbers persist, there could be some kind of caching going on. To detect this you could try to reorder the tests in you program or repeat the test triplet (like ABCABC).