LINQ orderby 与 IComparer

发布于 2024-09-12 19:13:05 字数 98 浏览 2 评论 0原文

我想知道用什么比较好。

用于对列表进行排序或 LINQ orderby 的 IComparer 类和 Compare 方法。两者都工作得很好,但哪一个更适合大型列表。

I would like to know what is better to use.

IComparer class and Compare method for sort or LINQ orderby on List. Both works fine but which one is better for large lists.

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

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

发布评论

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

评论(3

冬天的雪花 2024-09-19 19:13:05

我选择 LINQ 有两个原因。

如果您认为 OrderBy 子句中的 lambda 表达式编译为一个函数,那么我预计单线程实现的性能大致相似——无论如何,这几乎是您通过实现 IComparer 获得的全部结果。

话虽如此,通过更改排序算法以适应数据已排序的方式,而不是通过更改比较方法,您可能会获得更多的性能提升。但今天早上我愿意用我的咖啡打赌,Linq 语句中的 OrderBy 使用了 Quicksort 的实现,因此在一般情况下它可能已经相当不错了。

I would choose LINQ for two reasons.

  • LINQ queries are generally shorter and easier to read.
  • If you really do have a large number of elements, Linq also gives you the ability to scale out to multiple CPU cores by using PLinq, which might help you out significantly.

I would expect performance to be roughly similar for a single-threaded implementation, if you consider that the lambda expression in your OrderBy clause compiles to a function -- which is pretty much all you get by implementing IComparer anyway.

That being said, you might get more of a performance boost by changing your sort algorithm to be tailored to how your data is already sorted, rather than by changing your comparison method. But I'd be willing to bet my coffee this morning that OrderBy in your Linq statements uses an implementation of Quicksort, so it's probably pretty decent in the general case already.

叶落知秋 2024-09-19 19:13:05

对于所有基于集合的操作,我更喜欢默认使用 LINQ。这里的优点是我不必对所使用的集合的类型做太多假设(OrderBy 适用于 IEnumerable)。

无论如何,如果您有一个 IList,那么 List.Sort 可能会更快。

无论如何,在出现经过验证的(即测量的)性能问题之前我不会担心它

I prefer using LINQ by default for all collection-based operations. The advantage here is that I don't have to assume too much on the type of the collection used (OrderBy works on IEnumerable).

If you have an IList<T> anyway, then List.Sort will probably be faster.

Anyhow, I wouldn't worry about it before there is a proven (i.e. measured) performance problem

零崎曲识 2024-09-19 19:13:05

我认为从语义上讲,两者非常不同,IComparer 接口允许您定义类型如何自然排序,OrderBy 为您提供了一种按某些特定键对对象进行排序的方法,例如给定一个 Person 对象列表,对于查询 A 对列表进行排序名字,对于查询 B,按年龄对列表进行排序。

LINQ 为您提供了更大的灵活性,但如 OrderBy 需要一个 Func,它接受您的对象类型并返回一个用于排序的键,无论您返回什么键,仍然需要实现 IComparer 接口。

就大型列表的性能而言,根据您在 Compare 方法中所做的事情,我想象的两种方法之间可能几乎没有什么区别,尽管最好只是针对您的类型进行测试。

I think semantically the two are very different, IComparer interface lets you define how your type is sorted naturally, OrderBy gives you a way to sort your objects by some specific key, e.g. given a list of Person objects, for query A sort the list by First Name, for query B sort the list by Age.

LINQ gives you more flexibility, but as OrderBy requires a Func which takes your object type and returns a key to use for sorting, whatever key you return will still need to implement the IComparer interface.

In terms of performance on a large list, depending on what you're doing in the Compare method there are probably very little difference between the two approaches I'd imagine, though it's best to just test it out against your type.

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