To LINQ Or Not To LINQ - That is the Question

LINQ introduces inefficiencies in the form of hidden allocations. The C# Team's coding guidelines say:
1. Avoid LINQ
2. Avoid using foreach over collections that do not have a struct enumerator
3. Consider using an object pool. There are many usages of object pools in the compiler to see an example

Having a good understanding what LINQ is does internally should yield enough information to know whether you are taking a performance hit. LINQ, as a built-in technology, has performance advantages and disadvantages. The code behind the extension methods has had considerable performance attention paid to it by the .NET team.

The code shown in this video can be found here:

[VinuP]

Shiv, it's been some time you uploaded a video. I hope you are being safe there and doing well.
🙏😊

[avecesar]

I know your channel for almost 3 years.... now, I'm revisiting some of your videos, and you, without a pinch of doubt, are one of the most reliable source of knowledge here in YouTube.... you have a very nice way of explaining... not comparing, but its notable that you have, IMHO, a better set of soft-skills than other young and bold content creators.... experience expressed with a great charisma. Thank you.

[yogij]

No video from past 1 month. Hope you are keeping well! 🙏

[FH]

Hi Shiv, I hope you are doing well. It's been a while since you've posted this video. Eagerly looking forward to the new one. 🤞

[akhilbandari]

Hello Shiv

Thank you for sharing

Always good to see you with the basic core concepts, which are most important ones

[mselvam]

Thanks for this topic. I always have this question in my thoughts whenever I have to loop through... either to use LINQ or not LINQ.
This video makes it clear when to use. I really appreciate your effort and sharing the knowledge.

[saurabhchauhan]

Enjoyed watching this superb informative but getting knowledge like you on the memory level is tough. Glad I found you learned so much and I hope you are fine and safe !!!

[akimbbo_upnext]

You got crazy voice! thanks for video :)

[andrewthompson]

Amazing content as usual. I have to ask - What is that excellent color scheme and font you are using, and are they available for rider ?

[danielpassos]

what model of camera and microphone do you use to record videos?
nice video!

[sumanahaldar]

Maybe it’s a stupid question but I want to know what is the best way of doing this kind of performance testing (stopwatch???) ? Is there a tool which will give me the time it takes for each method to execute?

[hnmss]

I am sorry if you already mention it somewhere, but what camera and micro are you using for such an amazing quality? That's impressive!

[abdulkapoor]

I have two list object and contains crores of data in both list. I want to loop through with one other list and return a new set of list. Can you please give me the best solution for this to reduce the performance issues?

[Trhnetesiuz]

Thanks for the video, Kumar.
What color setup do you use in the Visual Studio? I really like the color combination.

[pagefault]

LINQ definitely allows you to easily do the wrong thing without realizing it. This is particularly true in - by supplying the comparer you're actually calling Enumrable.Contains(this IEnumerable<>, value, comparer) rather than HashSet<>.Contains(value) and it's enumerating the entire set each time. If the test sets were larger, this case would be orders of magnitude slower.

That said, a lot of the time, LINQ is not the real problem, the real problem is the data types and/or algorithms that LINQ is being asked to use. To that end, a much better solution is to realize in advance that you want to do case insensitive lookups in your HashSet<> and supplying an IEqualityComparer<> that matches your desired lookup.

public void GlobalSetup()
{
// snip

= new HashSet<string>(_verifiedCustomerNames,
= new HashSet<string>(_certifiedCustomerNames,
= new HashSet<string>(_aListCustomerNames,
}

[Benchmark]
public List<Customer>
{
return
_customers
.Where(c =>

||
||
}

Additionally, if you know you're going to need a "exists in any of these sets" a lot, it does make sense to pre-create that set as well, because you'll save on re-calculating the string hash 3x. That's surprisingly expensive, if it ends up in a hot path.

[Benchmark]
public List<Customer>
{
return
_customers
.Where(c =>

}

LINQ still has some overhead, and if it's truly a hot path you can combine the correct HashSet<>s with a non-LINQ enumeration, but just getting the data right up front already puts you ahead of "GetWithoutLINQForLoop".