the problem with ordering complex objects with using .OrderBy(x => x.Whatever) is that it creates a new object on the heap, thus adding to the strain on the garbage collector. the best way to attack the issue of ordering complex objects is to put static methods on the class such as "SortByAge", "SortByName" that returns an int. That way it morphs the actual IEnumerable in place rather than creating a new object on the heap. sure, i know functional programming's mantra and the side effects of changing the underlying model, but let's be real: Sometimes you want to give the user the ability to sort by name, by age, by country, by... a whole host of properties, and each time they click a button to re-order, it's a waste of memory allocations on the heap to create a new IEnumerable from the existing List or whatever. better and more efficient to sort in place.
Stuff like this is GREAT for continuing education. As a beginner I feel like I am jumping into a fast moving river 😂 I just need to go do a few of your courses and not do anything else for awhile to get basics down I think
Yep, focusing on learning the language instead of trying to keep up with the latest changes will be helpful. Not only will it give you a more solid target to hit, but it will also teach you how to deal with previous versions of .NET. For instance, in my C# Mastercourse, I teach .NET 6, but I also teach the .NET Framework. That's because you are going to see and have to work with the .NET Framework in "the real world".
Good question. My guess is that it will become a compiler exception in .NET 8, but I don't know for sure. There might be more to it than what I'm seeing.
0:00 Intro 0:21 Introduction to code 0:50 Old way of ordering 1:36 New way of ordering 1:57 Testing 2:23 Ordering complex objects 5:28 Order descending 6:13 Outro
Sorry for stupid question, but what about performance differences between Sort( ) and Order ( ) ? When use Sort ( ) and when Order ( ) ? Thanks a lot for your stunning educational videos!
It depends what you're sorting and how many of them there are. My experience is that for smaller lists, Sort is typically faster by a couple of percent, but on larger lists, OrderBy takes the lead. There are a lot of potential factors that go into that, though, so if you're worried about that extra couple of percent and you don't care whether it's an in-place sort vs. a separate copy, the best bet is to do timing tests on typical data and see what works best. Another factor to be aware of is that OrderBy produces what's called a "stable" sort...in other words, if two items compare the same, the one that came first in the original data will come first in the result. Sort doesn't guarantee that. My information might be out of date, though...v7 made a lot of improvements in some areas and this might be one of them. Either way, timing it in your particular use case is always going to be your best option.
OK, so I did some research and there is a bit of a benefit for using Order as opposed to OrderBy. Here is the post with more information (at the bottom of the LINQ section): devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/#linq
It's strange that they didn't add a generic type parameter constraint to require the element type implements IComparable for the Order and OrderDescending methods.
Please do tutorial for understanding and right usage of Native AOT. I can only use AOT for simple project but for complex such as JSON Serializing/Deserializing it doesn't work.
My guess is that this will come later on. Compile-time errors don't just happen - they need to be developed. In order to do that, you need to have the code to test them on. So I think it will come, unless there is something I missed in terms of complexity.
Nice but with Visual Studio AI learning, it's a double click of the 'Tab' key to write the code anyway. If it runs the same speed in a loop, then what is the point. Just another thing to rember in my view.
Everything takes effort. This is no exception. This was actually a tricky fix, and when they already had a functional and fairly easy-to-use solution, it wasn't deemed a high priority.
@@IAmTimCorey Maybe there is some underlying optimization/implementation hurdle I am not understanding then. I still remember being so frustrated by the lack of simple default ordering function when LINQ first came out almost 2 decades ago. I would have also made ordering of complex types default to ordering them by declaration order unless specifically defined with orderby
Why do they make things unnecessary complex? Orderby does do it's function and you don't have to think about complex values. I'm not happy with the way the. Net team is changing.
It feels like you are arguing that "OrderBy(x => x);" is less complex than "Order();" What I showed in this video is that Order works better for simple types and OrderBy works better for complex types. Now you have an option. If you don't want to use the new option, you don't have to. OrderBy isn't going anywhere.
I don't see why this is promoted as a new way of ordering in LINQ, as it is simple sugar method shortcuts for the corresponding `OrderBy{Descending}(x => x)` overloads. No less allocations at all. No performance gains. Just improved readability. Anyone could have created such custom extension methods in less than 5 min, no need to wait 10+ years for .NET7 to get such "new functionality" out of the box.
Because it can make some assumptions about your data, Order actually has less primary allocations for your data, resulting in better performance than OrderBy in the same scenario. Here is a link with more details: devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/#linq
Thank you for this. This is much quicker than reading through the detailed blog posts (which have their place of course).
You are welcome.
Thanks a lot! Best teacher ever!
Thank you!
the problem with ordering complex objects with using .OrderBy(x => x.Whatever) is that it creates a new object on the heap, thus adding to the strain on the garbage collector.
the best way to attack the issue of ordering complex objects is to put static methods on the class such as "SortByAge", "SortByName" that returns an int. That way it morphs the actual IEnumerable in place rather than creating a new object on the heap.
sure, i know functional programming's mantra and the side effects of changing the underlying model, but let's be real: Sometimes you want to give the user the ability to sort by name, by age, by country, by... a whole host of properties, and each time they click a button to re-order, it's a waste of memory allocations on the heap to create a new IEnumerable from the existing List or whatever.
better and more efficient to sort in place.
Stuff like this is GREAT for continuing education. As a beginner I feel like I am jumping into a fast moving river 😂 I just need to go do a few of your courses and not do anything else for awhile to get basics down I think
Yep, focusing on learning the language instead of trying to keep up with the latest changes will be helpful. Not only will it give you a more solid target to hit, but it will also teach you how to deal with previous versions of .NET. For instance, in my C# Mastercourse, I teach .NET 6, but I also teach the .NET Framework. That's because you are going to see and have to work with the .NET Framework in "the real world".
So glad to see folks like you getting excited about a feature I proposed ❤🎉
Thanks for getting it added. It is a nice option to have.
I really hope there are some more cool changes to LINQ, as this is pretty small! Thanks though, I wouldn't know about it if not for you.
You are welcome.
3:30 why is this a runtime exception?
shouldn't the compiler stop you from calling order on something which isn't Incomparable?
Good question. My guess is that it will become a compiler exception in .NET 8, but I don't know for sure. There might be more to it than what I'm seeing.
0:00 Intro
0:21 Introduction to code
0:50 Old way of ordering
1:36 New way of ordering
1:57 Testing
2:23 Ordering complex objects
5:28 Order descending
6:13 Outro
Thanks for sharing! I updated the video.
Top drawer content
Thank you!
Sorry for stupid question, but what about performance differences between Sort( ) and Order ( ) ? When use Sort ( ) and when Order ( ) ? Thanks a lot for your stunning educational videos!
u find out yet?
@@chezchezchezchez no...
I'd guess that sort is slower since it updates the underlying collection?
OrderBy is part of the fluent linq api. Since linq operates on IEnumerables, it is immutable. Sort mutates the source array / list.
It depends what you're sorting and how many of them there are. My experience is that for smaller lists, Sort is typically faster by a couple of percent, but on larger lists, OrderBy takes the lead. There are a lot of potential factors that go into that, though, so if you're worried about that extra couple of percent and you don't care whether it's an in-place sort vs. a separate copy, the best bet is to do timing tests on typical data and see what works best. Another factor to be aware of is that OrderBy produces what's called a "stable" sort...in other words, if two items compare the same, the one that came first in the original data will come first in the result. Sort doesn't guarantee that. My information might be out of date, though...v7 made a lot of improvements in some areas and this might be one of them. Either way, timing it in your particular use case is always going to be your best option.
Nice , 10min video series is 👌
Thank you!
Is there any performance difference when using any of these two, or is it just lowered by the compiler to the same source code?
Good question. I don't know the answer. My assumption is that they will be at least very similar.
OK, so I did some research and there is a bit of a benefit for using Order as opposed to OrderBy. Here is the post with more information (at the bottom of the LINQ section): devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/#linq
@@IAmTimCorey Thank you really much! Interested me a lot honestly
Спасибо за урок по LINQ
You are welcome.
THNX tim useful video and short .Sorting Algorithm
You are welcome.
It's strange that they didn't add a generic type parameter constraint to require the element type implements IComparable for the Order and OrderDescending methods.
Just posted the exact same question/observation. I see no reason to not do it that way, and you'd catch the error at compile time vs run time.
Please do tutorial for understanding and right usage of Native AOT.
I can only use AOT for simple project but for complex such as JSON Serializing/Deserializing it doesn't work.
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
Great video
Thanks!
As always thanks for your work! Awesome job
You are welcome.
Are there performance differences between the two?
Yes, there is a slight performance improvement.
Why doesn't it give compile-time error for Person object that it doesn't support IComparable? I expect compile errors in C# for this.
My guess is that this will come later on. Compile-time errors don't just happen - they need to be developed. In order to do that, you need to have the code to test them on. So I think it will come, unless there is something I missed in terms of complexity.
cool, thank you!
You are welcome.
Why didn't they just make Order() extend on IEnumerable to catch the error at compile time?
I'm not sure.
@@IAmTimCorey Fair enough. I appreciate the response.
Nice but with Visual Studio AI learning, it's a double click of the 'Tab' key to write the code anyway. If it runs the same speed in a loop, then what is the point. Just another thing to rember in my view.
There is a slight speed difference (improvement). Each now has a distinct use-case.
is there an equivalent of this with java? Great stuff!
java streams is an equivalent to linq
@@asdfxyz_randomname2133 thanks!
Hello Tim any chance you want to explain about cancel. tokens and how to use it correct. if possible in blazor server :)
Thanks for the suggestion. Please add it to the list on the suggestion site so others can vote on it as well: suggestions.iamtimcorey.com/
Insane how this wasn't implemented from the beginning
Everything takes effort. This is no exception. This was actually a tricky fix, and when they already had a functional and fairly easy-to-use solution, it wasn't deemed a high priority.
@@IAmTimCorey Maybe there is some underlying optimization/implementation hurdle I am not understanding then. I still remember being so frustrated by the lack of simple default ordering function when LINQ first came out almost 2 decades ago.
I would have also made ordering of complex types default to ordering them by declaration order unless specifically defined with orderby
thank you =)
You are welcome.
Soon c# will allow you to build entire systems with 20 lines of code.
Why do they make things unnecessary complex? Orderby does do it's function and you don't have to think about complex values. I'm not happy with the way the. Net team is changing.
It feels like you are arguing that "OrderBy(x => x);" is less complex than "Order();" What I showed in this video is that Order works better for simple types and OrderBy works better for complex types. Now you have an option. If you don't want to use the new option, you don't have to. OrderBy isn't going anywhere.
I don't see why this is promoted as a new way of ordering in LINQ, as it is simple sugar method shortcuts for the corresponding `OrderBy{Descending}(x => x)` overloads. No less allocations at all. No performance gains. Just improved readability. Anyone could have created such custom extension methods in less than 5 min, no need to wait 10+ years for .NET7 to get such "new functionality" out of the box.
Because it can make some assumptions about your data, Order actually has less primary allocations for your data, resulting in better performance than OrderBy in the same scenario. Here is a link with more details: devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/#linq
This feature really feels like unnecessary language bloat.
Why? It is a simplified syntax that actually saves some memory pressure as well.
seems like the most useless feature. ppl will be confused between order and sort.
They can use either. One is just simpler than the other. I'm not sure what confusion it would cause.