Stop Using FirstOrDefault in .NET! | Code Cop #021

Hello, everybody. I'm Nick, and in this episode of Code Cop, I will explain why you should be using FirstOrDefault over Find in C# even though people on LinkedIn might tell you otherwise.

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

Social Media:

#csharp #dotnet #codecop

[mynameisshadywhat]

Until I saw the Code Cop at the end of the title all my usages of FirstOrDefault flashed before my eyes

[hamzanasab]

Astronaut 1: Wait its a span?

Astronaut 2: Always has been 'shoots gun'

[TanelTeede]

"it's spans. It's ALWAYS spans." -- Nick

[Marfig]

Hi Nick. Coming late to this discussion. But this is a perfect example of why advice based on performance is usually a concern. Performance should never be the reason why a language feature should be chosen, unless performance is in fact a critical requirement at that time. We just need to remember to never pre-optimize. As the father of all computing advice once said, premature optimization is the root of all evil. Instead, Find, SingleOrDefault and FirstorDefault methods should be chosen based on their semantics. What is it the intent each of these three methods communicate? Chose the one that more accurately represent what you want to do. That's the type of advice that C# is lacking the most.

[kickback]

It seems unlikely that a significant bottleneck in an application will come from using "FirstOrDefault" over "Find" for List<T>. 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.

[typinowly]

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.

[torrvic]

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.

[Mosern]

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.

[pratyushkumarsingh]

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!!!

[sasukesarutobi]

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.

[NameOfTheDragon]

Any advice in the form "Use X because X is faster" is automatically suspect because it ignores the more important (in my humble but correct opinion) dimension of code readability. I get that there are situations where performance is key, but in the vast majority of situations it is not, and code quality is far more important. Premature optimization is the root of all evil. Know when performance matters and when it doesn't.

[Meryovi]

Analyzers suggesting the use of List (and Array) specific methods: Oh man, we screwed up.

[Juznik]

Love that you made a video about this. I was just on LinkedIn just this morning and saw this.

[antonmartyniuk]

Never use LINQ to filter data in the database, instead do all the filtering in memory 😅

[theFijian]

Does this mean using FirstOrDefault on a List<T> doesn't use Span?

[EddieVillamor]

I always had faith in linq optimization, glad they're pulling through! :)

[ShahidSyed-zk]

At 04:38, the Find method returns nullable of T which should return null in case element is not found in List<int>.

[vinny]

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.

[derriennovak]

Somehow I knew from the very beginning it will be spans :) Great video, as always.

[juaneszapatacano]

I didn't know about it. Great explanation!