Is Convert in Where bad?

Question

Given the following two cases, which one is preferable (If they're both bad, doing it a completely different way is an option too)?

Convert.ToInt32 called in Where:

 var items = GetItems();
 if (aDropDownList.SelectedIndex > 0) 
 {
     items = items.Where(x => 
             x.IntProperty == Convert.ToInt32(aDropDownList.SelectedValue));
 }

Convert.ToInt32 called before Where:

var items = GetItems();
 if (aDropDownList.SelectedIndex > 0) 
 {
     int selectedDropDownValue = Convert.ToInt32(aDropDownList.SelectedValue);
     items = items.Where(x => x.IntProperty == selectedDropDownValue);
 }

Answer 1

I would prefer the second. It does only one conversion, instead of many.

But unless this is a performance-critical piece of code (unlikely; it seems like GUI code), you won't notice a difference.

Answer 2

The only difference I can see is how the compiler would generate the lambda. In the second version, the value is captured and not referenced, and this will have an effect in a multithreaded environment.

Answer 3

Both of these have a flaw -

You're calling .Where(...) on the collection, but doing nothing with the results. This will have no effect whatsoever, since Where does not change the original collection - it returns a new IEnumerable<T> of items that match the predicate.

That being said, I'd prefer the second option- In the first option, the Convert.ToInt32 call will be run once for each element in your collection. In a small collection, this may not matter, but as the collection gets larger, it will get slower.

You may or may not notice that difference in this situation, but it's (IMO) a good practice to declare your variables prior to using a LINQ statement. I often see situations where people assume LINQ is slow merely because they're doing expensive calculations within their predicates. In this case, your method is relatively fast, so it probably will not matter, but as a practice, it's a good habit to follow the second pattern.