@@fusedqyou The "smart" ones are out preaching incomplete advice while the actual smart ones are busy doing real-life work and accomplishing something.
@@fusedqyou Even in the old version I would argue against it because find is more specialized. Sure it was faster, but for 99.9 % of use cases it will still be insignificant compared to even the fastest DB access the code does so if falls under premature optimization. Using FirstOrDefault means it will work for any enumerable so you can easily switch away from list if you need to and also change to singleordefault easily. And even IF you need the extra performance, depending on the use case find might not even be the best since you might have options to redesign the whole approach to get even more performance, and only after checking all that, falling back to an older more specific method should be used. At least in my opinion. Easy to read and maintain code is almost always the better code and old methods are often not as clear. FirstOrDefault is much more descriptive than Find since it includes how it handles not finding the value :)
@Natusch_ precisely. That's why my code reviews of others is usually passing quickly as long as there is something really bad, like never, and my code is always being dragged through idiotic nagging which have never resulted in any slightest improvements in any aspect so far. And yes, I have 30 years of uninterrupted experience while others have 8 tops. Your point explains it all.
I am getting sick of this kind of "advice". I would always just use, what I find is the most readable/understandable (even if it is the supposed inferior performing version). And if I find my application to slow down or uselessly crank up in memory usage, I investigate and optimize the bottleneck. No point in optimizing, what doesn't need to be optimized.
I agree with you. Plus -- the use-case for this is so simple and irrelevant... a better demonstration would be a list of a class type where the property of one of those classes matches.. with the caveat that the test data MUST have "duplicates" in there (or at least multiple records where the matching field has the same value -- and only return the FIRST of those...).
In my domain of work performance has high priority. So whenever I can squeeze out a little more performance, why not. For example I created a lot of methods in my general use library that allow me to set byte values in byte arrays using unsafe. I do that quite a lot, both on client and server side (namely for TCP/UDP communication), and why do something worse if better is possible? I know it's more performant, and I know it's often used. Should I default to some "simple", inferior standard instead, because so far it wasn't a bottleneck yet? When I am working on something, I have to load the entire system into memory. That's the best time to work on it, and also to improve it. When I am done with it, I will forget too much of it, and it would take days or weeks to get into it. If I'd switch domains too much, I'd lose out more time on that (without benefit) than what optimizations take in time - especially if they are necessary/beneficial later anyway.
@@brianviktor8212 Different projects have different performance requirements, but in my experience, premature optimization is often a curse. Why optimize for performance if it won’t significantly impact the app in the end? Especially if it comes at the cost of readability and maintainability. On top of that, you often need to make trade-offs between time and memory performance before you even know what kind of issue will cause a bottleneck. Of course, there are caveats. For example, I once worked on a originally statically rendered web-front-end where server-side queries to a specific data service were painfully slow, causing frequent timeouts. As a result, we implemented client-side caching and effectively built a modern JavaScript app for this one use case, allowing users to begin working while the data loaded. But months later, we finally reviewed the data server’s code and found the issue - a poorly scaling lookup-loop with multiple database queries inside each iteration. A single, somewhat ugly, database query fixed the issue. If the initial developer had been more performance-focused, this might have been avoided. However, management also could have listened when we identified the server as the bottleneck. Instead of a simple back-end fix, we spent months optimizing the front-end, which became unnecessary once the real issue was fixed. In the end, I prioritize readability. If a problem comes up, it's important that any competent team member - not just the original developer - can understand the code’s intent and fix the issue. Readability ensures that the team can adapt and optimize when it matters, using clear helper functions and selective comments to guide future changes (in general I dislike comments, but sometimes they are important). This way, the code may initially “perform worse”, but it’s maintainable by the whole team. At least that is the idea :D
Number of times an in memory lookup has been the culprit of slowness in my professional life, is pretty darn few. Its always disk, network, database or some other external thingy.
It seems unlikely that a significant bottleneck in an application will come from using "FirstOrDefault" over "Find" for List. It's possible and for those of us that cannot upgrade our version of .NET due to external dependencies, that might be a reasonable optimization (assuming this is the problem). However, based on profiling we have done, our slowdowns are not this simple. Usually, issues are caused by repeated calls to our 3d party dependency for the same information over and over. TL;DR: Profile first, optimize later.
Oh, on longer collections this is very likely. On lists with 10 items, you don't notice the difference. Remember you never remove bottlenecks. If you remove the bottleneck you know, you make another piece of code your bottleneck. Maybe the Find is a 2nd or 3nd order degree of bottleneck.
I think that Nick is a smart boy and I really admire young people nowadays for being that smart. Always high quality advices from Nick. His school and teachers must be really very proud of him.
This is a great point that performance advice is so specific to versions and implementations. Forgetting this seems to be the cardinal sin of all these advice posts.
I don't think comparing against a pre-release version of .Net is necessarily fair to disqualify the advice. It's good advice UNTIL .Net 9 comes out which makes this concern trivial.
And maybe now someone goes in and optimizes the Fins method. Since they know what the backing array is it will be faster than the Linq method. So the whole point is once again valid and anything can be optimized by Microsoft at any time...
I'd like to say it's a good advice until .NET 10 comes out as many projects migrate only to LTS versions. But, well, it's good only for hot parts of your code ehich greatly affect the performance (if any). Most of your code is not a hot path and don't bottleneck the performance
@@YT-dr8qi There are people who care about LTS? There is no practical difference between 18 or 36 months. Applications live 20 years or longer. And you're not going to get budget to upgrade applications without any practical improvement for business and especially not when you're using beta features like Blazor that still get big breaking changes every single new release. Choosing your .NET version is about which features you need. Through most of an applications' life, LTS/STS won't be a factor.
Okay so Find is specific to List vs FirstOrDefault which works on all data types. So you loose reusability and type agnostic code for a tiny bit of performance? Oh and if you use .NET 9 its actually faster. Yeah, stick to FirstOrDefault because regardless of the performance its better to have something that is type agnostic.
@@NotACat20 No it's not fastest, but EF Core is certainly up there with the most popular ORMs. I personally don't have a problem with its implementation of the UoW pattern. EF Core can handle that. There are a few methods available such as FromSql and ExecuteSqlInterpolated that allow for constructing dynamic SQL.
@@junior.santana It does, but because Unity is reaaaally slow with updating to newer C# versions, Linq's performance is not that great and can be a real fps killer.
My first thought would be "are you only searching for one thing, or multiple things"? More often then not it is multiple things, in the context of a loop (or several nested loops). At which point I would use HashSet, Dictionary, or a lookup table. I have lost count of the number of times I have seen other developers use Find (or First, or FirstOrDefault) for everything, no matter the context. Also, I almost never use a List directly these days. I might use ICollection, IReadOnlyList, or IEnumerable. Which might be backed by a list. Or it might not. So I rarely if ever optimize for a specific collection type, and when I do I'm usually back to using HashSet or Dictionary.
Also, remember that Linq query extensions like FirstOrDefault and SingleOrDefault queries can be converted to SQL by Entity Framework, Collection specific methods might not have those optimizations, and might cause higher bandwidth between the application and database, same applies to Any vs Array,Exists etc. So always using collection specific methods is ill adviced by that alone.
So basically Microsoft was lazy and didn't optimize Find 😉 I still don't think it's bad advise to use a specialized method over a LINQ method as it could be optimized further than the LINQ method. Probably not significantly in this case, but it's a good principle.
I feel like the take away here is not that you use FirstOrDefault over Find because Microsoft is prioritizing it, but that contextless performance advice akin to "use this not this" should not be blindly followed without a deeper understanding and up-to-date knowledge. Over all I would even say that the original advice is not wrong. Its just gonna be out of date soon.
This was fantastic and honestly my mind was indeed blown with those results from .NET 9. Once I saw it was spans it made sense, I'm pretty excited to learn about what other optimizations were made in .NET 9 now. My question now is - what happens to programs that were compiled in .NET 8 but run in .NET 9? I assume they also get the optimizations because the methods in the runtime are what got optimized, but I don't know how much implementation is inlined into your program by the compiler vs. what is left as calls into the runtime.
I am a little curious about the performance on "not found". These tend to have very different characteristics. Other than that, just this week, I have been looking at replacing FirstOrDefault with Find on a .NET 8 project. Looks like it is good...until we switch to 9 (or probably 10)
Crazy that TryGetFirst doesn't return a boolean but the found element, and sets the bool found as the out parameter. Maybe it's a memory allocation optimization or something but it looks weird.
You need to have a bool that tells you if the element was found or not. Other languages like C++ use an iterator that points to past end in case element was not found (there is no need for this pair: value + found)
@@MarincaGheorghe I understand, but usually TryXXX methods return the boolean, and set the found/parsed/whatever element as the out value, so you can write: "if (TryXXX(obj, out var xxx)) { doSomething(xxx); }"
@@MarincaGheorghe the issue is that it works the opposite of how every other Try method works reutrn bool if sucessful and out the result so you can simplyfy the code by doing if(Try)
Theoretically, just looking at the name, find wouldn't neccessarily need to iterate in order, so if you had list.FirstOrDefault(x => x.Firstname == "John") and list.Find(x => x.Firstname == "John"), it could get you a different object. But in this case, Find iterates in order and the difference is just enumerator overhead.
It may depend on the company, as not all companies are going to update their applications every time a new .NET version is released. Maybe if you are working on a project that can be upgraded frecuently, It can be a good advice, but if not, finding an optimal approach to that implemented version can be a better option.
I generally take the approach of using linq until I have a good reason not to. I know a lot of optimizations are in place that may be better than mine, it gets updated and is very versatile. Plus I know it will work on any collection if it changes in the future. Once I have/need a specific behavior more attached to the specific collection or type, then I think about doing it differently
At 4:06 I thought it might've been a local issue where Rider no longer jumps to the appropriate definition now on the first attempt. It loads the source files and then you have to go back and re-jump. I hope they fix that soon b/c I swear it used to work
Seems like MS wouldn't have to rewrite Find to use Spans so much as just point Find to the whatever method the FirstOrDefault is using and then maybe handle the result differently? I didn't look too closely at the code
Can you update the test to have a sealed IntWrapper and test & compare it across 8 & 9? Optimally have a test with the latest Framework version for library maintainers Maybe just make it a RUclips Short, if it isn't enough content
Hi @Nick, very nice video. You always surprise me with your content. Can you make video how you are able to drill down to built in/library code. Thanks
Another reason why you shouldn't write custom code to replace readable and consise linq unless you absolutely have to for performance reasons. Your custom approach is unlikely to get optimized by using a new version, whereas builtin code might.
Im working with a company that takes a long time to update dotnet, is it not worth making this chantge, since we are stil on dotnet 7? Performance is important for our software
Find also happens to be a list only linq method. Many libraries only return ienumerables. If you have to convert an ienumerable to a list it’s going to to be slower than firstordefault.
Find isn't a linq method. It came along in 2.0 with List in System.Collections.Generic and uses a Predicate. They also created a Array.Find with a Predicate in 2.0 for all the boomers who didn't want to move on from arrays. LINQ (System.Linq) and lambda expressions (System.Linq.Expressions) were added in 3.5. and while thinking more globally about this whole concept, they moved on to using the Func/Action philosophy. But yeah for sakes of compatibility or refactoring it makes way more sense to work against IEnumerable than IList. There are concepts that become forgotten as more and more the .NET environment becomes littered by javascriptification of it's languages and specifically aiming at C# as a victim.
@@krs-tube The person I replied to said "a list only linq method" so I explained it's not a linq method. So take your own advice and get some social lessons while you're at it.
@@krs-tube He said it but never fully explained why it was bad and what the consequences were…. I guess you just like posting mean comments for a dopamine hit…. Thanks for your useful comment
It's telling that you have an EF preface. The problem is always that people want one way of doing things. We have a hammer and want everything to be nails. Personally, I dislike the name "Find". To me, it implies it should act more like Where+ToList, where I am filtering and potentially getting back multiple objects. should be renamed to "FindFirst" if that is what it is doing.
Very insightful analysis but I have to disagree somewhat on not using something that currently performs better because Microsoft will eventually optimize it.
It's highly situational. And picking the right method is what separates good engineers for mediocre. If you really, really need that performance right now, then use Find. If you don't care all that much and don't want to refactor code, then use Linq everywhere and play the odds that it'll get faster and faster over time.
You are somewhat right. It all depends on the situation. If you think you can upgrade the code later with latest version, then it's fine. But most of the times i would go for something more general/generic. I'll just have to increase the version & i get the benefits.
Another example of being too smart for your own good. Or rather generalizing over a broader topic based on specific example. Your method runs slow? Profile it and find the lowest hanging fruit. Cautiously build a heuristic over it, but only to potentially detect similar issues in the future and not to dismiss one type/method over another.
@@NotACat20 The idea of using a profiler is to lower the bar of things that are responsible for the major slowdowns in your application, so it is pretty profilable, yes, it is not rubbish.
Func is definitely more descriptive, since you can see it returns a bool without knowing what a predicate means. Also Func can have more than one (16 in fact) input types. Predicate is just a very specific implementation, feels redundant.
@@artemisDev yes thats what the name predicate implies. We have one condition and it can be either true or false. So when you read predicate somewhere normally you should know that you can pass down some expression that should return either true or false.
A Predicate is just one very specific version of Func. Meanwhile, the Func can be Func, Func, Func, etc. They realized that the Func (or Action) generics covered everything, and that the specialized versions like Predicate were just kind of confusing and slightly non-compatible. There's no functional difference in behavior between a Func and a Predicate, but you can't substitute one for the other because they are different types (although a lambda can be converted to either). I believe only the Array and List classes use Predicate, while LINQ always uses Func. Since LINQ is preferred for almost everything, and LINQ tries to have a unified syntax, encountering a specialized form of Func just introduces a confusion that doesn't need to be there. "Predicate" is definitely more descriptive (for me; I don't know about everyone else), but it introduces the concept of specialized terms that act as 'exceptions' to the general Func rule, and that's just a conceptual 'leak' that you're better off not surfacing in the language syntax. And it's "not modern" because Predicate was introduced way early, before MS realized it was a bad idea. Unfortunately, by then they couldn't get rid of it, so now it's mostly just, "Please ignore this little bit of legacy trivia", or "Use LINQ instead."
@@artemisDev a predicate IS a condition that should evaluate to `true` when applied to something. The name `Predicate` carries semantic meaning that `Func` does not.
OK, I made my comments because I'm always calling a DB with LINQ... With memory collections, I'm usually on the client... I guess I can use it with Blazor though... There are a lot of cases where you want to keep data local rather than call the DB for lookups...
@@nickchapsas Sure, same reason why you'd write a delegate type rather than use a raw Func/Action in parameters or variables, because it improves readability. In this case it's already done for you.
@@artemisDev those factors should be fairly equivalent, since they're executing identical predicates in an identical manner to find a match. Only difference is the Enumerator, so I'd personally expect the same performance delta between ref types as there was between value types...
And why exactly is advising people on how to use LINQ properly in the current LTS considered bad advice simply because a prerelease of an STS changes performance? Yes, the benchmarks didn't match the sample code in the image. Yes that is misleading. Yes value and reference types behave differently. But the advice was sound in the current LTS. Taking someone's advice and saying it is bad simply because it changes in a prerelease of an STS is silly
This is one of those videos I quite don't like, not something like "you don't want to use the default implemented method of the type", it goes against what is designed in the language itself and feels like a very artificial advice.
If there is an older and a newer implementation inside the language library, use the new one. I think that's a good advice. IT's two different "default implementations". You have to go "against what is designed in the language" in either way.
Premature optimization. There’s usually something else your doing that results in multi second responses you should fix before going down this rabbit hole.
What rabbit hole, lol? This is a bizarre take for something that is neither absurd not problematic, it is an almost free thing you could do. And while I agree that your project to this exclusively because of optimization factors is a premature optimization, doing this from start will not be a problem.
Meh. Microsoft can optimize LINQ all they want. Won't do you any good if your projects are .NET Core 3.1 in production and no one is planning to change that
SingleOrDefault doesn't go through a collection twice the length. It finds first match and continues to look for one more match, which in worst case leads to the end of the collection, and that's it.
And if the first match is in the middle of the collection and there isn’t a second match, the it goes twice the length, which is what I said in the video
Dangit, Sonarqube is flagged all of my FirstOrDefaults in my projects and telling me to replace them with Find..... And I've made the change to make it quit nagging me...
you use FirstOrDefault because the name is more precise, that how you can also tell that find is an old version. And if you dont care about this, you always build the loop yourself, because LINQ was garbage performance since release. good to see thats getting better.
"Microsoft will optimize LINQ in every release because they know how much it is used" -- Yet it took them until v9 of Core (setting aside all the years of full Framework) to optimize this?
Span was only introduced in 2017. It takes time for folks to discover where it can be utilised, and I'm sure they're getting better at that as time goes on.
I find your title confusing. I admit I'm not a very regular viewer, but I read the title initially as what your final advice is, not the original claim that you're going to dispute as the Code Cop. If you'd put "Stop Using FirstOrDefault" in quotes followed by code cop, that would make it clearer, imo, that someone else said to stop and you don't agree.
Who is going to code cop this video? The conclusion of the video is based on changing the project framework to a version that isn't officially released yet. This advice is probably not practical for majority of large scale applications as it's not feasible for them to switch to an RC version of .NET at the drop of a hat. Not to mention that there will be tonnes of large enterprise applications that still run on .NET framework. The original post is right for majority of situations, whereas your advice is only valid for .NET 9?
@@nickchapsas for legacy (existing?) systems, from a logistical point of view, yes. New products are written in current official release version (dotnet 8 at time of writing)
Unless your app is making millions ($) per hour, this is so pointless.... honestly dont have to time to worry about nanoseconds in my code that get's hit maybe a thousand times a day.
![BLACK BAG - Official Trailer [HD] - Only in Theaters March 14](http://i.ytimg.com/vi/Du0Xp8WX_7I/mqdefault.jpg)
Until I saw the Code Cop at the end of the title all my usages of FirstOrDefault flashed before my eyes
Literally he drops these and I’m like “okay boys what are we refactoring today” 😂
😂🤣😂🤣i stopped listening
Exactly this, I hate the code cop vids.
😂
They are the best way to learn things in a practical, real-world way
Astronaut 1: Wait its a span?
Astronaut 2: Always has been 'shoots gun'
"it's spans. It's ALWAYS spans." -- Nick
I wanna subscribe to Nick's OnlySpans
This deserves an Oscar 🤣@@tedchirvasiu
Can someone care to explain?
@@silkfire Maybe Indiana Jones? He did not like snake case as I remember...
@@tedchirvasiu ohmygod LMAOO
I hate LinkedIn. Everyone's out to prove how special they are. And it's never the smart ones doing it.
The smart ones don't care much about how you do it as long as you're accomplishing real life solutions in a sufficient or, ideally, great way.
@@fusedqyou The "smart" ones are out preaching incomplete advice while the actual smart ones are busy doing real-life work and accomplishing something.
@@fusedqyou Even in the old version I would argue against it because find is more specialized. Sure it was faster, but for 99.9 % of use cases it will still be insignificant compared to even the fastest DB access the code does so if falls under premature optimization.
Using FirstOrDefault means it will work for any enumerable so you can easily switch away from list if you need to and also change to singleordefault easily.
And even IF you need the extra performance, depending on the use case find might not even be the best since you might have options to redesign the whole approach to get even more performance, and only after checking all that, falling back to an older more specific method should be used.
At least in my opinion.
Easy to read and maintain code is almost always the better code and old methods are often not as clear.
FirstOrDefault is much more descriptive than Find since it includes how it handles not finding the value :)
@Natusch_ precisely. That's why my code reviews of others is usually passing quickly as long as there is something really bad, like never, and my code is always being dragged through idiotic nagging which have never resulted in any slightest improvements in any aspect so far. And yes, I have 30 years of uninterrupted experience while others have 8 tops. Your point explains it all.
@@tuckertcs He who can does. He who cannot, teaches.
I am getting sick of this kind of "advice". I would always just use, what I find is the most readable/understandable (even if it is the supposed inferior performing version). And if I find my application to slow down or uselessly crank up in memory usage, I investigate and optimize the bottleneck. No point in optimizing, what doesn't need to be optimized.
totally agree,. call it optimized for readabillity.
Preemptive optimizing is pure evil.
I agree with you. Plus -- the use-case for this is so simple and irrelevant... a better demonstration would be a list of a class type where the property of one of those classes matches.. with the caveat that the test data MUST have "duplicates" in there (or at least multiple records where the matching field has the same value -- and only return the FIRST of those...).
In my domain of work performance has high priority. So whenever I can squeeze out a little more performance, why not. For example I created a lot of methods in my general use library that allow me to set byte values in byte arrays using unsafe. I do that quite a lot, both on client and server side (namely for TCP/UDP communication), and why do something worse if better is possible? I know it's more performant, and I know it's often used.
Should I default to some "simple", inferior standard instead, because so far it wasn't a bottleneck yet? When I am working on something, I have to load the entire system into memory. That's the best time to work on it, and also to improve it. When I am done with it, I will forget too much of it, and it would take days or weeks to get into it.
If I'd switch domains too much, I'd lose out more time on that (without benefit) than what optimizations take in time - especially if they are necessary/beneficial later anyway.
@@brianviktor8212 Different projects have different performance requirements, but in my experience, premature optimization is often a curse. Why optimize for performance if it won’t significantly impact the app in the end? Especially if it comes at the cost of readability and maintainability. On top of that, you often need to make trade-offs between time and memory performance before you even know what kind of issue will cause a bottleneck.
Of course, there are caveats. For example, I once worked on a originally statically rendered web-front-end where server-side queries to a specific data service were painfully slow, causing frequent timeouts. As a result, we implemented client-side caching and effectively built a modern JavaScript app for this one use case, allowing users to begin working while the data loaded. But months later, we finally reviewed the data server’s code and found the issue - a poorly scaling lookup-loop with multiple database queries inside each iteration. A single, somewhat ugly, database query fixed the issue.
If the initial developer had been more performance-focused, this might have been avoided. However, management also could have listened when we identified the server as the bottleneck. Instead of a simple back-end fix, we spent months optimizing the front-end, which became unnecessary once the real issue was fixed.
In the end, I prioritize readability. If a problem comes up, it's important that any competent team member - not just the original developer - can understand the code’s intent and fix the issue. Readability ensures that the team can adapt and optimize when it matters, using clear helper functions and selective comments to guide future changes (in general I dislike comments, but sometimes they are important). This way, the code may initially “perform worse”, but it’s maintainable by the whole team. At least that is the idea :D
Number of times an in memory lookup has been the culprit of slowness in my professional life, is pretty darn few.
Its always disk, network, database or some other external thingy.
Or wrong algorithm!
@@odomobo - yes, some unintended nested loops is a fun one.
True, the other big one in managed code in general is HEAP churn which I do optimise for. Otherwise, clean code all the way.
It seems unlikely that a significant bottleneck in an application will come from using "FirstOrDefault" over "Find" for List. It's possible and for those of us that cannot upgrade our version of .NET due to external dependencies, that might be a reasonable optimization (assuming this is the problem). However, based on profiling we have done, our slowdowns are not this simple. Usually, issues are caused by repeated calls to our 3d party dependency for the same information over and over.
TL;DR: Profile first, optimize later.
Oh, on longer collections this is very likely. On lists with 10 items, you don't notice the difference.
Remember you never remove bottlenecks. If you remove the bottleneck you know, you make another piece of code your bottleneck.
Maybe the Find is a 2nd or 3nd order degree of bottleneck.
My jaw dropped when i saw the .net 9 results
I think that Nick is a smart boy and I really admire young people nowadays for being that smart. Always high quality advices from Nick. His school and teachers must be really very proud of him.
This is a great point that performance advice is so specific to versions and implementations. Forgetting this seems to be the cardinal sin of all these advice posts.
I had a hunch that Nick is going to create the video on this when I had first seen it on LinkedIn 😂 and here we are!!!
I don't think comparing against a pre-release version of .Net is necessarily fair to disqualify the advice. It's good advice UNTIL .Net 9 comes out which makes this concern trivial.
And maybe now someone goes in and optimizes the Fins method. Since they know what the backing array is it will be faster than the Linq method. So the whole point is once again valid and anything can be optimized by Microsoft at any time...
I'd like to say it's a good advice until .NET 10 comes out as many projects migrate only to LTS versions.
But, well, it's good only for hot parts of your code ehich greatly affect the performance (if any). Most of your code is not a hot path and don't bottleneck the performance
@@YT-dr8qi There are people who care about LTS? There is no practical difference between 18 or 36 months. Applications live 20 years or longer. And you're not going to get budget to upgrade applications without any practical improvement for business and especially not when you're using beta features like Blazor that still get big breaking changes every single new release.
Choosing your .NET version is about which features you need. Through most of an applications' life, LTS/STS won't be a factor.
@@Rizon1985 we have 3 internals apps, we upgrade them for every new LTS
At 04:38, the Find method returns nullable of T which should return null in case element is not found in List.
Analyzers suggesting the use of List (and Array) specific methods: Oh man, we screwed up.
I was about to say... I've had analyzers yelling at my for years to use Find on lists. In this guy's defense, it's been like this for years.
Okay so Find is specific to List vs FirstOrDefault which works on all data types. So you loose reusability and type agnostic code for a tiny bit of performance? Oh and if you use .NET 9 its actually faster. Yeah, stick to FirstOrDefault because regardless of the performance its better to have something that is type agnostic.
Never use LINQ to filter data in the database, instead do all the filtering in memory 😅
Huh why?
@@Anonymous-un2nj it's a joke.
An example of bad advice 😜
Nah, roll your own SQL to do it 😅
@@NotACat20 No it's not fastest, but EF Core is certainly up there with the most popular ORMs. I personally don't have a problem with its implementation of the UoW pattern.
EF Core can handle that. There are a few methods available such as FromSql and ExecuteSqlInterpolated that allow for constructing dynamic SQL.
Excel is the only way
Cries in Unity
Why? Doesn't Unity support Linq?
@@junior.santana It does, but because Unity is reaaaally slow with updating to newer C# versions, Linq's performance is not that great and can be a real fps killer.
@@testitestmann8819 I see. That's annoying, it's a use case that would benefit a lot from those micro-optimizations
My first thought would be "are you only searching for one thing, or multiple things"? More often then not it is multiple things, in the context of a loop (or several nested loops). At which point I would use HashSet, Dictionary, or a lookup table. I have lost count of the number of times I have seen other developers use Find (or First, or FirstOrDefault) for everything, no matter the context. Also, I almost never use a List directly these days. I might use ICollection, IReadOnlyList, or IEnumerable. Which might be backed by a list. Or it might not. So I rarely if ever optimize for a specific collection type, and when I do I'm usually back to using HashSet or Dictionary.
Also, remember that Linq query extensions like FirstOrDefault and SingleOrDefault queries can be converted to SQL by Entity Framework, Collection specific methods might not have those optimizations, and might cause higher bandwidth between the application and database, same applies to Any vs Array,Exists etc. So always using collection specific methods is ill adviced by that alone.
The message was: If you have a known collection type: use it. Not vice versa. Don't create lists, to use it.
1:46 that is wrong, if duplicate exist Single method throw exception that's not applicable for First or FirstDefault
So basically Microsoft was lazy and didn't optimize Find 😉 I still don't think it's bad advise to use a specialized method over a LINQ method as it could be optimized further than the LINQ method. Probably not significantly in this case, but it's a good principle.
I feel like the take away here is not that you use FirstOrDefault over Find because Microsoft is prioritizing it, but that contextless performance advice akin to "use this not this" should not be blindly followed without a deeper understanding and up-to-date knowledge.
Over all I would even say that the original advice is not wrong. Its just gonna be out of date soon.
This also applies for Any/Exists: Exists was faster than Any, but in .NET 9, Any has been optimized to outperform Exists.
This was fantastic and honestly my mind was indeed blown with those results from .NET 9. Once I saw it was spans it made sense, I'm pretty excited to learn about what other optimizations were made in .NET 9 now. My question now is - what happens to programs that were compiled in .NET 8 but run in .NET 9? I assume they also get the optimizations because the methods in the runtime are what got optimized, but I don't know how much implementation is inlined into your program by the compiler vs. what is left as calls into the runtime.
Is Predicate considered old-hat now? I thought it was basically just a shorthand way of saying Func ?
Yes, it's simply physicly older, .net 2.0 vs. .net 3.5; which is 2003 vs. 2007 or so.
I am a little curious about the performance on "not found". These tend to have very different characteristics.
Other than that, just this week, I have been looking at replacing FirstOrDefault with Find on a .NET 8 project. Looks like it is good...until we switch to 9 (or probably 10)
Crazy that TryGetFirst doesn't return a boolean but the found element, and sets the bool found as the out parameter. Maybe it's a memory allocation optimization or something but it looks weird.
You need to have a bool that tells you if the element was found or not. Other languages like C++ use an iterator that points to past end in case element was not found (there is no need for this pair: value + found)
@@MarincaGheorghe I understand, but usually TryXXX methods return the boolean, and set the found/parsed/whatever element as the out value, so you can write: "if (TryXXX(obj, out var xxx)) { doSomething(xxx); }"
@@MarincaGheorghe the issue is that it works the opposite of how every other Try method works
reutrn bool if sucessful and out the result so you can simplyfy the code by doing if(Try)
I still don't understand how Find can be faster in .NET 8 if the methods basically do the same thing... is it something in the IL?
It’s the enumerator
find is specialized for list, allowing faster access
Theoretically, just looking at the name, find wouldn't neccessarily need to iterate in order, so if you had list.FirstOrDefault(x => x.Firstname == "John") and list.Find(x => x.Firstname == "John"), it could get you a different object.
But in this case, Find iterates in order and the difference is just enumerator overhead.
Love that you made a video about this. I was just on LinkedIn just this morning and saw this.
It may depend on the company, as not all companies are going to update their applications every time a new .NET version is released. Maybe if you are working on a project that can be upgraded frecuently, It can be a good advice, but if not, finding an optimal approach to that implemented version can be a better option.
I generally take the approach of using linq until I have a good reason not to.
I know a lot of optimizations are in place that may be better than mine, it gets updated and is very versatile. Plus I know it will work on any collection if it changes in the future.
Once I have/need a specific behavior more attached to the specific collection or type, then I think about doing it differently
But is there an alternative to FirstOrDefaultAsync? Thank you.
I saw that advice and was still chewing on it, I'm glad you did this Nick. I was wondering if the LINQ optimizations were being considered.
Somehow I knew from the very beginning it will be spans :) Great video, as always.
At 4:06 I thought it might've been a local issue where Rider no longer jumps to the appropriate definition now on the first attempt. It loads the source files and then you have to go back and re-jump. I hope they fix that soon b/c I swear it used to work
Seems like MS wouldn't have to rewrite Find to use Spans so much as just point Find to the whatever method the FirstOrDefault is using and then maybe handle the result differently? I didn't look too closely at the code
Can you update the test to have a sealed IntWrapper and test & compare it across 8 & 9?
Optimally have a test with the latest Framework version for library maintainers
Maybe just make it a RUclips Short, if it isn't enough content
How hard is it to optimize .Find/.Exists to match that, not that hard. Just get a span instead of for looping. (if someone just opens an issue)
Hi @Nick, very nice video. You always surprise me with your content. Can you make video how you are able to drill down to built in/library code. Thanks
I always had faith in linq optimization, glad they're pulling through! :)
Another reason why you shouldn't write custom code to replace readable and consise linq unless you absolutely have to for performance reasons. Your custom approach is unlikely to get optimized by using a new version, whereas builtin code might.
I’m using the Array specific Find and Exists methods as SonarQube advised me to do. We’re on .Net 8 right now, maybe I should run some benchmarks.
You could say instead that you do not use FirstOrDefault on in-memory collections, but should use it in EntityFramework ?
Find and FirstOrDefault work differently in EF
Im working with a company that takes a long time to update dotnet, is it not worth making this chantge, since we are stil on dotnet 7? Performance is important for our software
Find also happens to be a list only linq method. Many libraries only return ienumerables. If you have to convert an ienumerable to a list it’s going to to be slower than firstordefault.
Find isn't a linq method. It came along in 2.0 with List in System.Collections.Generic and uses a Predicate. They also created a Array.Find with a Predicate in 2.0 for all the boomers who didn't want to move on from arrays. LINQ (System.Linq) and lambda expressions (System.Linq.Expressions) were added in 3.5. and while thinking more globally about this whole concept, they moved on to using the Func/Action philosophy.
But yeah for sakes of compatibility or refactoring it makes way more sense to work against IEnumerable than IList. There are concepts that become forgotten as more and more the .NET environment becomes littered by javascriptification of it's languages and specifically aiming at C# as a victim.
@@krs-tube The person I replied to said "a list only linq method" so I explained it's not a linq method.
So take your own advice and get some social lessons while you're at it.
@@Rizon1985 I tagged the wrong person in my reply, appologies fam!
Nick specifically said and shown that .Find is a method on List() I guess you watched carefuly before dropping your hot take
@@krs-tube He said it but never fully explained why it was bad and what the consequences were…. I guess you just like posting mean comments for a dopamine hit…. Thanks for your useful comment
I cannot find any Blazor Deep Dive course. Is it currently being recorded?
Yes, Jimmy is currently working on it
Could you make a video about spans and why they are so cool?
Everyone who has been using FirstOrDefault breaths a sigh of relief..
That is a decent improvement in performance for free!
Great video! I would like to see how this method behaive with EF
That was one hell of a thriller! I enjoyed it the way one would enjoy watching Hitchcock's movies.
It's telling that you have an EF preface. The problem is always that people want one way of doing things. We have a hammer and want everything to be nails. Personally, I dislike the name "Find". To me, it implies it should act more like Where+ToList, where I am filtering and potentially getting back multiple objects. should be renamed to "FindFirst" if that is what it is doing.
Why is span iteration faster than array iteration!?
It's more based on pointer arithmetics, like in C++.
Very insightful analysis but I have to disagree somewhat on not using something that currently performs better because Microsoft will eventually optimize it.
It's highly situational. And picking the right method is what separates good engineers for mediocre. If you really, really need that performance right now, then use Find. If you don't care all that much and don't want to refactor code, then use Linq everywhere and play the odds that it'll get faster and faster over time.
You are somewhat right. It all depends on the situation. If you think you can upgrade the code later with latest version, then it's fine. But most of the times i would go for something more general/generic. I'll just have to increase the version & i get the benefits.
@@shahzaibhassan2777 Yep
I would rely on solar analysers to remove the cognitive load
Another example of being too smart for your own good. Or rather generalizing over a broader topic based on specific example.
Your method runs slow? Profile it and find the lowest hanging fruit. Cautiously build a heuristic over it, but only to potentially detect similar issues in the future and not to dismiss one type/method over another.
@@NotACat20
The idea of using a profiler is to lower the bar of things that are responsible for the major slowdowns in your application, so it is pretty profilable, yes, it is not rubbish.
Why would you prefer `Func` over `Predicate`? The latter is more descriptive. What makes it "not modern"? Seems arbitrary to me.
Func is definitely more descriptive, since you can see it returns a bool without knowing what a predicate means. Also Func can have more than one (16 in fact) input types.
Predicate is just a very specific implementation, feels redundant.
@@artemisDev yes thats what the name predicate implies. We have one condition and it can be either true or false.
So when you read predicate somewhere normally you should know that you can pass down some expression that should return either true or false.
A Predicate is just one very specific version of Func. Meanwhile, the Func can be Func, Func, Func, etc. They realized that the Func (or Action) generics covered everything, and that the specialized versions like Predicate were just kind of confusing and slightly non-compatible.
There's no functional difference in behavior between a Func and a Predicate, but you can't substitute one for the other because they are different types (although a lambda can be converted to either). I believe only the Array and List classes use Predicate, while LINQ always uses Func. Since LINQ is preferred for almost everything, and LINQ tries to have a unified syntax, encountering a specialized form of Func just introduces a confusion that doesn't need to be there.
"Predicate" is definitely more descriptive (for me; I don't know about everyone else), but it introduces the concept of specialized terms that act as 'exceptions' to the general Func rule, and that's just a conceptual 'leak' that you're better off not surfacing in the language syntax.
And it's "not modern" because Predicate was introduced way early, before MS realized it was a bad idea. Unfortunately, by then they couldn't get rid of it, so now it's mostly just, "Please ignore this little bit of legacy trivia", or "Use LINQ instead."
@@artemisDev a predicate IS a condition that should evaluate to `true` when applied to something. The name `Predicate` carries semantic meaning that `Func` does not.
OK, I made my comments because I'm always calling a DB with LINQ... With memory collections, I'm usually on the client... I guess I can use it with Blazor though... There are a lot of cases where you want to keep data local rather than call the DB for lookups...
4:17 I don't see why `Predicate` would not be used anymore when it's clearer than a general `Func`?
Is it?
@@nickchapsas Sure, same reason why you'd write a delegate type rather than use a raw Func/Action in parameters or variables, because it improves readability. In this case it's already done for you.
@@fusedqyouUnfortunately readability isn’t objective. Look at Ruby.
@@alanschmitt9865 Wasn't my point, though? Why would it not be used anymore regardless?
@@fusedqyou Because someone on the .NET team disagrees with you on readability I suppose.
Dayum... why is the wrapped version so much worse in .NET 8?
Something bizarre is going on there...
Cost of de-referencing, memory lookups, cache fails perhaps?
@@artemisDev those factors should be fairly equivalent, since they're executing identical predicates in an identical manner to find a match.
Only difference is the Enumerator, so I'd personally expect the same performance delta between ref types as there was between value types...
And why exactly is advising people on how to use LINQ properly in the current LTS considered bad advice simply because a prerelease of an STS changes performance?
Yes, the benchmarks didn't match the sample code in the image. Yes that is misleading. Yes value and reference types behave differently. But the advice was sound in the current LTS.
Taking someone's advice and saying it is bad simply because it changes in a prerelease of an STS is silly
I agree with you completely. This video seems to be in bad taste.
This is one of those videos I quite don't like, not something like "you don't want to use the default implemented method of the type", it goes against what is designed in the language itself and feels like a very artificial advice.
If there is an older and a newer implementation inside the language library, use the new one. I think that's a good advice. IT's two different "default implementations". You have to go "against what is designed in the language" in either way.
🎵 span, span, span, span, lovely spaaaaaaan, lovelyyyy spaaaaaan 🎵
why use .NET 9 in production when it doesn't have LTS?
I had to use Find instead of FirstOrDefault because we treat warning as error and analyser was flagging that as warning.
thank you for this series, I learn a lot
Premature optimization. There’s usually something else your doing that results in multi second responses you should fix before going down this rabbit hole.
What rabbit hole, lol? This is a bizarre take for something that is neither absurd not problematic, it is an almost free thing you could do. And while I agree that your project to this exclusively because of optimization factors is a premature optimization, doing this from start will not be a problem.
No, that's bad code
@@diadetediotedio6918 It's more important to have readable code than chase micro-optimization.
what is so special about spans?
I have a full video talking about this
Why don’t you put your courses on Udemy?
Why would I do that?
Saw this post on LinkedIn today😅
Meh. Microsoft can optimize LINQ all they want. Won't do you any good if your projects are .NET Core 3.1 in production and no one is planning to change that
You have to advertise .NET 8 and collect pro arguments.
You speak as fast as your code runs in dotnet 9, however I prefer find method talk speed😂
I try to avoid SingleOrDefault, but that's just because of the cost of throwing an exception.
Wow - you are blowing my mind
well ... kind of
Stephen Toub is doing his magic 😂
SingleOrDefault doesn't go through a collection twice the length. It finds first match and continues to look for one more match, which in worst case leads to the end of the collection, and that's it.
And if the first match is in the middle of the collection and there isn’t a second match, the it goes twice the length, which is what I said in the video
@@nickchapsas ah, then I misunderstood you, sorry!
Writing about LINQ on LinkedIn???
Dangit, Sonarqube is flagged all of my FirstOrDefaults in my projects and telling me to replace them with Find..... And I've made the change to make it quit nagging me...
Sure, it might be slower, but I'll still use FirstOrDefault over Find.
you use FirstOrDefault because the name is more precise, that how you can also tell that find is an old version.
And if you dont care about this, you always build the loop yourself, because LINQ was garbage performance since release.
good to see thats getting better.
"Microsoft will optimize LINQ in every release because they know how much it is used" -- Yet it took them until v9 of Core (setting aside all the years of full Framework) to optimize this?
Span was only introduced in 2017. It takes time for folks to discover where it can be utilised, and I'm sure they're getting better at that as time goes on.
@@BenMcCallums Oh, so _only_ 6 or 7 major releases ago? :)
I mean, they're special-casing arrays and lists here. Other types won't receive that same optimization (including chained Linq queries).
Really nice advice!
Man we’re all the same, we think just about one single thing… spans!
Plot twists in this video 😱😱😱
i'm guessing it is the same situation with .NET Framework.
Good work Microsoft
I'm hoping this is a what not to do... You use FirstOrDefaultAsync so you will return null...
I find your title confusing. I admit I'm not a very regular viewer, but I read the title initially as what your final advice is, not the original claim that you're going to dispute as the Code Cop. If you'd put "Stop Using FirstOrDefault" in quotes followed by code cop, that would make it clearer, imo, that someone else said to stop and you don't agree.
Haha I had seen this one 2 or 3 days ago on LinkedIn xD
Well that is really great, People in my company still using 4.8 framework LOL. so Find it is.
Thanks for the explanation,
Code Cop?! Issue arrest warrants for some of the guys on my dev team please! They are bad offenders!
The reason the OP takes microseconds instead of nanoseconds is because they are running the benchmark on a potato.
Мое почтение Нику и ребятам из Майкрософт.
Who is going to code cop this video? The conclusion of the video is based on changing the project framework to a version that isn't officially released yet. This advice is probably not practical for majority of large scale applications as it's not feasible for them to switch to an RC version of .NET at the drop of a hat. Not to mention that there will be tonnes of large enterprise applications that still run on .NET framework. The original post is right for majority of situations, whereas your advice is only valid for .NET 9?
Are you stuck in .NET Framework?
@@nickchapsas for legacy (existing?) systems, from a logistical point of view, yes. New products are written in current official release version (dotnet 8 at time of writing)
code cop, funny!
Unless your app is making millions ($) per hour, this is so pointless.... honestly dont have to time to worry about nanoseconds in my code that get's hit maybe a thousand times a day.
I use Where() then FirstOrDefault() 😅😅😅😅😅😅
네이티브 코드를 짜는게 최선이라고 하던가.. c언어가 cpp보다 빠르니 c를 사용해야해 라는 구시대적 개발론 .. 그냥 어셈블리로 짜는게 가장 즇은 해안이네.. 어셈블리야 말로 개떡같은 코드 짜기 딱좋지...
Why is it much slower for reference types than for value types in .NET8?
reference type have an additional indirection than values which can be placed in continuous memory. I guess it's this.
Good sample, but the title is kind of misleading 🤔