Stop using LINQ to order your primitive collections in C#

Hello everybody I'm Nick and in this video I will show you a couple of new LINQ methods introduced in .NET 7 that you probably shouldn't be using. There are some even faster and more memory efficient alternatives that you can use instead, depending on your usecase.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet

[maksymkyian]

Another important thing to mention is that Array.Sort() and List.Sort() perform unstable sort, so they not preserve the order of elements that have the same key, while LINQ .OrderBy performs stable sort, so never changes places of the equal keys. This could be useful (and even required) when you work with collections of non-primitive types (and this is probably the reason why OrderBy is using slower sorting algorithms).

[Mr__B.]

Thanks for your continuous efforts and insightful content, Nick! Your dedication to exploring and explaining complex software topics is truly appreciated. I’m especially inspired by your recent discussions on performance improvements. It would be fantastic to see similar advancements in the manipulation of reference type object collections. Keep up the great work!

[tymekmajewski]

I think it's worth pointing out that `random.Next()` is a significant factor in the order(by) test cases and it *dominates* the sort test case.

Without the hundred calls to `random.Next` the Sort() benchmark will be several times quicker for both the list and the array.

[kazepis]

Great video Nick! I was really hoping that you would run the benchmarks with the Params attribute to see what happens with 1_000, 10_000 and 1_000_000 sized collections. I would also really like to see the results from the sort using spans method. Really great video though as always! Keep them coming…

[jongeduard]

I have been testing around a lot with those OrderBy and Sort methods (both Array and List indeed) in the past, and I also discovered that smart self-choosing sorting algorithm stuff on especially those Sort methods indeed. And if I am right a native code version of those algorithms is chosen as well when possibile.
I noticed in certain situations, you're indeed better off with the Sort methods than with linq OrderBy, but in real life these cases are very limited, because very often there is the more important decision to make is at which moment you actually want to store your data in a memory buffer (like array / list) anyway, or if just enumerating once is enough.
Personally I remember that I noticed this with file / directory enumeration if I remember it right.
Choosing your sorting method is one problem to solve, but an actual program has a lot more factors, with filtering and buffering as well.

[SubVengeance]

Theos! You are my defacto no.1 resource for C# on YouTube. Enjoying the flow and straight to the point vids. I tip my hat for you sir :)

[welltypedwitch]

2:45 Wait, why does the lambda need to allocate? It doesn't capture any variables, so it seems like the compiler should be able to allocate it statically, right?

[Spirch]

(still watching) at 7:45 should you the random in the method too? each method wont reset the seed which mean the benchmark are ran with different set of numbers

[julkiewitz]

I believe that a static lambda like x => x with no closure will not allocate anything. It's compiled as a static method in the using class scope. It can be seen by decompiling the output managed DLL. Only delegates and lambdas that actually capture some state will be compiled to a separate class that then needs to be instantiated (which causes the allocation). No closure delegates will have their object set to null.

[KnightSwordAG]

If you wanted to do a descending order, I believe you can chain a Reverse() to the List as well. It may be slightly slower, but given the improvements overall, it may be worth it.

[th_CAV_Trooper]

In most cases I'd rather pay the cost in time for the side-effect free operations.

[NakaT]

wich is your Visual Studio Theme nick?

[cn-ml]

You probably shoulnt initialize the list in the benchmark method. Also, for the seed to have an effect, shoulnt you rather set the seed and init the array in an IterationSetup method? That way every benchmark iteration operates on the same array?

[Kundrtcz]

Order/OrderBy advantages:
+ purity (i.e. doesn't change underlying collection)
+ simplicity
+ readability
+ same for primitive/complex types
+ extension method of IEnumerable<T> => you don't have to have a collection before and ToArray/ToList can be way down the chain of other methods
+ expression tree (allows for other optimizations etc.)

Sort advantages:
+ faster (not always)
+ more memory efficient

So it depends. I believe Order/OrderBy is better choice in most of the cases. Title of the video is a bit misleading.

[flybyw]

Shouldn't you re-seed the Random for each Enumerable for the same values, especially with int.ToString()?

[vamvdotnet]

Hey Nick! I have suggestion for your next video! Since performance is your thing, why not talking about ObjectPool<T>?
Kind regards,
Cristiano Dias

[kyryllvlasiuk]

Do linq methods perform sort immediately, or can it be deferred or halted. Like say we order and take 100 out of a million, will the performance be the same as we array sort said million. I would benchmark it later, now I am from phone. But if someone beats me to it, you are welcome.

[HAMYLABS]

In most cases, I'd say the readability of Linq sorts is more useful than the potential performance upsides of using in-place sorts. Would probably recommend starting with that then moving to in-place if performance becomes a bottleneck.

[tarekel-shahawy]

What aout sorting objects using a property inside them, I think that's the most important use case.
Can we use List.Sort with IComparison In that case?

[jadenrogers]

How are you on RC1? Site still says SDK 7.0.100-preview.7