I’m assuming that by “allocates like crazy”, you mean creates objects on the heap quite a bit. Which it does… relatively speaking.
But compare some of those actions to the amount of memory that would have to be allocated in a none linq setting. And you’ll have comparable amount of memory usage. Sometimes lower for super simple linq statement, often times larger for things like sorting.
For example:
non-linq
foreach (var obj in someList)
{
if(obj.SomeBooleanTest) //do stuff
}
linq
foreach(var obj in from o in someList where o.SomeBooleanTest select o)
{
//do stuff
}
Sure the non-linq will be less, there’s no extra anonymous enumerable being created in memory.
But lets say that list needed to be sorted, made distinct, like in numberkruncher’s example.
// The following array contains a collection of numbers:
var someNumbers = GetRandomCollectionOfNumbers();
// Now, using Linq you can get all unique even numbers and sort ascending with the following:
var uniqueEvenSorted = someNumbers
.Where(n => n % 2 == 0)
.Distinct()
.OrderBy(n => n);
//note I removed the ToArray because that processes the entire list immediately, I often don't need it as an array
//actually I use arrays very rarely in my code... when I do they're mostly static in size and don't change much if at all after construction... such as field members for a component that the inspector needs.
(I don’t even want to post the alternative non-linq code, it’d be so damn messy)
Well, that’ll require a bit more objects in created on the heap. Both in the linq and non-linq methods. Thing is… how efficient will the average programmers sort technique be? They’ll probably end up using the built in sorting algorithms supplied by .Net (just like linq will use), but done with arrays most likely. And will probably need copies of the arrays made as well and so on. You’ll be creating a lot of objects, taking up lots of memory, and having to manage all those objects.
Allocating like crazy…
And you have to do all the work yourself.
And then comes the last thing, which is the main reason I like Linq so much. If you do this… I bet you’ll probably write the code that does this all up front. Processing the list, sorting it, etc, all BEFORE you go and actually loop over it. Requiring a bunch of up front processing time.
The linq alternative, it processes as you need it. Say I loop through some linq statement, and I stop mid-way. It stops… it doesn’t process anymore, it doesn’t allocate anymore, it stops with me. I sort, and process half way through the list, it has no need to sort the back end of the list… so it doesn’t.
Sure all this functionality could be done, by hand, but will require a whole bunch of leg work, and is hardly readable. Causing you to create your own linq like library… like Smooth P did (which may or may not over come of the flaws in linq, and may or may not introduce its own flaws).
That last bit though, the processing of the list as I need it. That’s the part that sells me the most.
I also use linq in Update methods all over the place and barely see a performance hit relative to other options… but my linq statement also are in the realm of things that other options would be just as costly. And if the performance hit is so bad, but can be pre calculated on say load, I would do so instead.