为什么 Date1.CompareTo(Date2) > 0 比 Date1 快 >日期2?

发布于 2024-09-13 12:07:51 字数 1350 浏览 2 评论 0原文

另一个“不重要”的性能问题。 不重要,因为大多数代码可读性比几毫秒重要​​得多,但无论如何都很有趣。 我注意到不同的日期时间比较之间存在差异。

我检查了 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. Date1 > Date2 = 13207/13251/13267/13569/13100 = 13279 ms
  2. Date.Compare(Date1, Date2) > 0 = 13510/13194/13081/13353/13092 = 13246 毫秒
  3. 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:

  1. Date1 > Date2 = 13207/13251/13267/13569/13100 = 13279 ms
  2. Date.Compare(Date1, Date2) > 0 = 13510/13194/13081/13353/13092 = 13246 ms
  3. 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

腹黑女流氓 2024-09-20 12:07:51

让我们在这个函数上使用一些 Reflector-Magic(全部来自 DateTime-Type):

Operator " > "

public static bool operator >(DateTime t1, DateTime t2)
{
    return (t1.InternalTicks > t2.InternalTicks);
}

private long InternalTicks
{
    get
    {
        return (((long) this.dateData) & 0x3fffffffffffffffL);
    }
}

// this.dateData is a private field

Compare

public static int Compare(DateTime t1, DateTime t2)
{
    long internalTicks = t1.InternalTicks;
    long num2 = t2.InternalTicks;
    if (internalTicks > num2)
    {
        return 1;
    }
    if (internalTicks < num2)
    {
        return -1;
    }
    return 0;
}

CompareTo

public int CompareTo(DateTime value)
{
    long internalTicks = value.InternalTicks;
    long num2 = this.InternalTicks;
    if (num2 > internalTicks)
    {
        return 1;
    }
    if (num2 < internalTicks)
    {
        return -1;
    }
    return 0;
}

让我们把它分解一下:

Operator >

  • 针对私有属性的两次调用
  • 每次调用发出一次强制转换和一次二进制 And

Compare 和 CompareTo

  • 创建两个变量并比较它们

< code>CompareTo 很可能更快,因为它不需要访问外部对象,而是可以从自身提取变量之一。

编辑:通过查看函数,我意识到 > 的性能应始终保持不变,而 Compare的性能>CompareTo 基于传递的值:

  • t1 更大:最快
  • t2 更大:中间
  • t1 == t2:最慢

不过,我们正在谈论的性能增益或损失是......我该怎么说。 ..我一点也不在乎。 ;)但是这很有趣,我同意。

Let's use some Reflector-Magic on this functions (all from the DateTime-Type):

Operator " > "

public static bool operator >(DateTime t1, DateTime t2)
{
    return (t1.InternalTicks > t2.InternalTicks);
}

private long InternalTicks
{
    get
    {
        return (((long) this.dateData) & 0x3fffffffffffffffL);
    }
}

// this.dateData is a private field

Compare

public static int Compare(DateTime t1, DateTime t2)
{
    long internalTicks = t1.InternalTicks;
    long num2 = t2.InternalTicks;
    if (internalTicks > num2)
    {
        return 1;
    }
    if (internalTicks < num2)
    {
        return -1;
    }
    return 0;
}

CompareTo

public int CompareTo(DateTime value)
{
    long internalTicks = value.InternalTicks;
    long num2 = this.InternalTicks;
    if (num2 > internalTicks)
    {
        return 1;
    }
    if (num2 < internalTicks)
    {
        return -1;
    }
    return 0;
}

Let's break it down:

Operator >

  • Two calls against a private property
  • Each call issues one cast and one binary And

Compare and CompareTo

  • Creates two variables and compares them

CompareTo is most likely faster because it does not need to access an outside 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 of Compare and CompareTo are based on the passed values:

  • t1 is greater: fastest
  • t2 is greater: middle
  • t1 == t2: slowest

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.

全部不再 2024-09-20 12:07:51

如果这些数字持续存在,则可能存在某种缓存。要检测到这一点,您可以尝试重新排序程序中的测试或重复测试三元组(如 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).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文