LINQ Overhead

[Mythran]

Consider the following:

List<int> ints = new List<int>();
for (int i = 0; i < 20; i++) {
ints.Add(i);
}

// EXAMPLE 1
var strings =
from i in ints
where i > 0 && i < 10 select i.ToString();

foreach (string s in strings) {
Console.WriteLine(s);
}

// EXAMPLE 2
foreach (int i in ints) {
if (i > 0 && i < 10) {
Console.WriteLine(i.ToString());
}
}


Now, what kind of overhead are we looking at for using LINQ in EXAMPLE 1
compared to using just the 'if' statement as shown in EXAMPLE 2? I have
multiple code blocks that I've redone to use LINQ and have started thinking
if I shouldn't have when a simple 'if' statement would do the trick just
fine....what do you peeps think?

Thanks a bunch!

Mythran

::I'm NOT a zero, I'm a one (just don't ask my wife)::

 

[Peter Morris]

Best way to know is to use bigger numbers and try it. You will be surprised
at LINQ's performance.

 

[Gregory A. Beamer \(Cowboy\) - MVP]

When a hammer works, why by a pneumatic wrench?

I am not sure there is much overhead in LINQ, but performance is not the
only reason you use one programming construct over another. There is also
clarity of code (a maintainability issue). If you can use a simple if, I am
not sure iffing with LINQ is your best option.

LINQ is best when you have a set you need to filter, etc. It is great at
manipulating objects that conform to IEnumerable. While you can create
objects holding simple types, and then iterate, why add the extra complexity
to the code?

Just my two cents.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

Subscribe to my blog
http://feeds.feedburner.com/GregoryBeamer#

or just read it:
http://feeds.feedburner.com/GregoryBeamer

********************************************
| Think outside the box! |
********************************************

 

[Jon Skeet [C# MVP]]

Consider the following:

List<int> ints = new List<int>();
for (int i = 0; i < 20; i++) {
        ints.Add(i);
}

If you're only going to iterate through this, don't forget about
Enumerable.Range(0, 20)

Now, what kind of overhead are we looking at for using LINQ in EXAMPLE 1
compared to using just the 'if' statement as shown in EXAMPLE 2?  I have
multiple code blocks that I've redone to use LINQ and have started thinking
if I shouldn't have when a simple 'if' statement would do the trick just
fine....what do you peeps think?

I think you should write the most readable code that gets the job
done, *but* test performance regularly, and have definite performance
goals. There's an overhead to LINQ to Objects, but it's not
particularly high. In most cases, it's not a problem. In a few cases,
it will be. Your profiler will help to tell you which is which

Jon

 

[Jon Skeet [C# MVP]]

Consider the following:

List<int> ints = new List<int>();
for (int i = 0; i < 20; i++) {
        ints.Add(i);
}

If you're only going to iterate through this, don't forget about
Enumerable.Range(0, 20)

Now, what kind of overhead are we looking at for using LINQ in EXAMPLE 1
compared to using just the 'if' statement as shown in EXAMPLE 2?  I have
multiple code blocks that I've redone to use LINQ and have started thinking
if I shouldn't have when a simple 'if' statement would do the trick just
fine....what do you peeps think?

I think you should write the most readable code that gets the job
done, *but* test performance regularly, and have definite performance
goals. There's an overhead to LINQ to Objects, but it's not
particularly high. In most cases, it's not a problem. In a few cases,
it will be. Your profiler will help to tell you which is which

Jon

 

[Mythran]

If you're only going to iterate through this, don't forget about
Enumerable.Range(0, 20)



I think you should write the most readable code that gets the job
done, *but* test performance regularly, and have definite performance
goals. There's an overhead to LINQ to Objects, but it's not
particularly high. In most cases, it's not a problem. In a few cases,
it will be. Your profiler will help to tell you which is which

Jon

This was just an example, and I would take a look at using the Range method
instead if this was real-world code....I just wanted to know that in
general, where a simple statement would work, why would I choose LINQ over
the simpler set....? Well, the answer that I've gathered from the replies
would be...I wouldn't.

Thanks,
Kip