Anyways, I haven't actually used LINQ for anything, but I've seen it around. You know, caught a glimpse here and there, so that I have a vague idea what it's for and what it looks like. Naturally the biggest question I have is, How fast is it?
From what I understand, it is most efficient when used on an IQueryable, but works on anything that's IEnumerable. Okay, fair enough. The C# foreach keyword works on IEnumerables too. Consequently, every time you increment, it checks the bounds, moves next, etc. Compared to a for loop, it's expensive--but not so much so.
I ran across this post from Steve Hebert today, thanks to Google, and it verified much of what I was thinking and fearing about LINQ: it's inefficient.
But let's face it, it's not LINQ's fault, and I think that article (and the comments) make that abundantly clear. It has limitations, and if you don't know about them, and don't take advantage of LINQ when it has the upper hand, you will fail.
Fair enough. You should always know how your underlying data structures and algorithms work, or you'll end up making bad choices, with or without LINQ. A linked list, for example, would make a wonderful priority queue, because removing the first element is a O(1) operation. However, adding would be O(n), since it has to traverse the entire list. If you use a generic List
The real point I'm trying to make here is that LINQ has it's limitations. It might be very easy to write, but perform very badly if it is unable to take into consideration all of the knowledge that you, as a developer, know about the data structure you are using, and the nature of the data inside it.
On the other hand, there are situations where it will compile into the exact same code, in which case you might actually appreciate the concise and straight-forward syntax that it offers you.
No comments:
Post a Comment