更高效的compareTo算法?

发布于 2024-11-10 04:12:28 字数 460 浏览 0 评论 0原文

我正在使用 Collections.sort 对对象的 ArrayList 进行排序,并且我想看看是否有更有效的compareTo 方法来完成我想要做的事情。

方法如下:

@Override
public int compareTo(Song s) {
    if (runningTime > s.runningTime) {
        return -1;
    } else if (runningTime < s.runningTime) {
        return 1;
    }
    int lastCmp = title.compareTo(s.title);
    return (lastCmp != 0 ? lastCmp : composer.compareTo(s.composer));
}

如果有人可以建议一种更有效的方法(即更快的运行时间),我将非常感激。

I'm using Collections.sort to sort a ArrayList of objects, and I want to see if there is a more efficient compareTo method for what I'm trying to do.

Here's the method:

@Override
public int compareTo(Song s) {
    if (runningTime > s.runningTime) {
        return -1;
    } else if (runningTime < s.runningTime) {
        return 1;
    }
    int lastCmp = title.compareTo(s.title);
    return (lastCmp != 0 ? lastCmp : composer.compareTo(s.composer));
}

If anyone could suggest a more efficient method (i.e. quicker runtime) I would be very grateful.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

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

发布评论

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

评论(4

戒ㄋ 2024-11-17 04:12:28

就像 MeBigFatGuy 所说,任何改进都是微不足道的,但我认为你仍然可以稍微清理一下代码以减少不必要的 if-else 条件。我的两分钱。

public int compareTo(Song s) {
    if (runningTime != s.runningTime) {
        return s.runningTime - runningTime;
    }
    else {
        int lastCmp = title.compareTo(s.title);
        return (lastCmp != 0 ? lastCmp : composer.compareTo(s.composer));
    }
}

Just like MeBigFatGuy said, any improvement is insignificant, but I think you can still clean up the code a bit to reduce unnecessary if-else condition. My two cents.

public int compareTo(Song s) {
    if (runningTime != s.runningTime) {
        return s.runningTime - runningTime;
    }
    else {
        int lastCmp = title.compareTo(s.title);
        return (lastCmp != 0 ? lastCmp : composer.compareTo(s.composer));
    }
}
垂暮老矣 2024-11-17 04:12:28

假设歌曲排序的优先级是固定的(运行时间;如果运行时间相同,则为标题;如果运行时间和标题相同,则为作曲家),那么您就没有什么可以做得更好的了。如果优先级没有固定,那么也许在标题之前测试作曲家可能会加快速度;这取决于您的实际数据。我会首先测试运行时间,因为这总是比字符串比较更快。

Assuming that the priority of song ordering is fixed (running time; title if running times are the same; composer if running times and titles are the same), then there's not much you can do better. If the priorities are not fixed, then perhaps testing on composer before title may speed things up a bit; it depends on your actual data. I'd keep the test on running times first, because that is always going to be faster than string comparisons.

萤火眠眠 2024-11-17 04:12:28

我看起来也不错。如果遇到性能问题,您可以检查排序是否过于频繁。不确定 Collections.sort 现在是否对此敏感,但是如果您在仅插入几首歌曲后不使用已排序的列表,您可能会有所收获

Looks fine to me as well. If you're running into performance problems, you might check if you're sorting too often. Not sure if Collections.sort is sensitive to this by now, but you might gain sth if you don't resort an already sorted list after inserting only a few songs

安人多梦 2024-11-17 04:12:28

根据读取属性值所需的时间,首先将 runningTime 和 s.runningTime 存储到局部变量中可能会稍微快一些。因此,平均而言,您每次调用只需阅读一次,而不是每次调用阅读 1.5 次或更多次。

Depending on how long it takes to read a property value, it might be a tiny bit quicker to store runningTime and s.runningTime into local variables first. So on average, instead of reading them 1.5 or more times per call, you'd only read them once per call.

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