Is Linq worth it?

  • Thread starter Thread starter SurturZ
  • Start date Start date
S

SurturZ

Is it worth spending time learning this Linq thingummy, or is it going to be
another flash-in-the-pan like "ActiveX Documents"?

My initial impression is that it will be hard to optimise Linq queries if
they aren't fast enough.
 
I've found it to be one of the few worthwhile new technologies that MS have
released with .NET 3.5 actually.

The amount of times I've written code that iterates through
collections/arrays looking for particular elements that meet specific
criteria is quite significant, and I didn't realise it until I started using
Linq for things. In terms of performance I've found it to be more than
acceptable and uses optimised hashing when doing joins etc which probably
gives it some advantages. It's really not that hard to write specific
functions to optimise slower queries either, at least not in my experience.

Consider this in terms of elegance for example:

Old:

Dim myList As New List(Of Integer), myEvenList As New List(Of Integer)

'<Snip> Init myList with lots of random integers

' Now find the even numbers

For Each i as Integer in myList
If i / 2 = i \ 2 Then myEvenList.Add(i)
Next


New:

Dim myList As New List(Of Integer)
'<Snip> Init myList with lots of random integers

Dim myEvenList = (From i In myList Where i / 2 = i \ 2).ToList



The one occasional catch-me-out I've found is that the query isn't actually
executed until you try and use the result for something. So until I access
some property in myEvenList (such as an element in it) then it hasn't really
run the query. Most of the time this won't bother you and sometimes you can
find significant performance boosts if your code-path never actually
accesses the resulting list.

-Alex
 
Alex said:
The one occasional catch-me-out I've found is that the query isn't
actually executed until you try and use the result for something. So
until I access some property in myEvenList (such as an element in it)
then it hasn't really run the query. Most of the time this won't
bother you and sometimes you can find significant performance boosts
if your code-path never actually accesses the resulting list.
Click to expand...

(Still in .Net 2.0, so I can't try it yet).

Are you saying that if you did

Dim myList As New List(Of Integer)
'<Snip> Init myList with 1,2,3,4,5,6,7,8,9

Dim myEvenList = (From i In myList Where i / 2 = i \ 2).ToList

then did
'<Snip> Add to myList 10,11,12,13,14

then displayed the contents of myEvenList, you would get
2,4,6,8,10,12,14?

I guess that's okay, but the code doesn't read that way to me. What you describe
sounds more like a filter on a dataview. What if you wanted just the even
numbers there were in there to start with, but not the ones added later?
 
SurturZ said:
Is it worth spending time learning this Linq thingummy, or is it going to be
another flash-in-the-pan like "ActiveX Documents"?

My initial impression is that it will be hard to optimise Linq queries if
they aren't fast enough.
Click to expand...

Learn it. It will change your life, or at least the coding portion of it!
I'm sure there will be some kind of LINQ 2.0, but it makes many processes
trivial.
 
My initial impression is that it will be hard to optimise Linq queries if
they aren't fast enough.
Click to expand...

So don't use them always, there is no reasonable person who tells you to go
by car to Australia as you are living in the USA or vice versa. Did you
count how many alternatives you have for almost every problem in VB for Net

Cor
 
Hi Steve,
(Still in .Net 2.0, so I can't try it yet).

Are you saying that if you did

Dim myList As New List(Of Integer)
'<Snip> Init myList with 1,2,3,4,5,6,7,8,9

Dim myEvenList = (From i In myList Where i / 2 = i \ 2).ToList

then did
'<Snip> Add to myList 10,11,12,13,14

then displayed the contents of myEvenList, you would get
2,4,6,8,10,12,14?

I guess that's okay, but the code doesn't read that way to me. What you
describe sounds more like a filter on a dataview. What if you wanted just
the even numbers there were in there to start with, but not the ones added
later?
Click to expand...


Yes and no. In the example I listed, I called the .ToList method of
myEvenList which in turn caused the query to immediately execute and store
its results (as at that time) into that List<T> variable. Had I not called
that method, then the behaviour you described (output includes 10, 12, 14)
would occur. As you correctly point out, it is actually a filter but that
isn't necessarily un-intuitive. If you think of it as just a SQL query (but
one that executes on an in-memory variable like an array) then the results
of a SQL query are always dependent on what data is in the source table at
the time of execution.

It's actually very useful in the sense that you can have an IEnumerable
variable which in this case always returns the even numbers from myList no
matter how many times you modify the content of myList. Alternatively you
can just call .ToList (or .ToArray, or .ToDictionary) and take a snapshot
right then and there (essentially by running the query and copying the
results into the appropriate generic variable).

There are many parts of Linq that aren't all that intuitive or necessarily
readable until you know exactly what the syntax is (Lambda expressions
anyone?) and at first glance it looks like ass-backward SQL code, but the
power of it is immense and I'm only scratching the surface with what I'm
using it for. I'm a lot more excited about what I can use Linq for than I
am over the WPF/WCF/WF/WWF/WWE/Smackdown technologies that MS are ramming
down everyone's throats at the moment, and have found it to be one of the
most useful additions to the language. Things like anonymous types and type
inference were also added to support Linq in the first place, and they too
are very welcome side effects.


-Alex :-)
 
Hi Alex:

Alex said:
It's actually very useful in the sense that you can have an
IEnumerable variable which in this case always returns the even
numbers from myList no matter how many times you modify the content
of myList. Alternatively you can just call .ToList (or .ToArray, or
.ToDictionary) and take a snapshot right then and there (essentially
by running the query and copying the results into the appropriate
generic variable).
Click to expand...

Okay, that sounds better. I like having it both ways: dynamic, but also the
ability to get a snapshot.
There are many parts of Linq that aren't all that intuitive or
necessarily readable until you know exactly what the syntax is
(Lambda expressions anyone?) and at first glance it looks like
ass-backward SQL code, but the power of it is immense and I'm only
scratching the surface with what I'm using it for. I'm a lot more
excited about what I can use Linq for than I am over the
WPF/WCF/WF/WWF/WWE/Smackdown technologies that MS are ramming down
everyone's throats at the moment, and have found it to be one of the
most useful additions to the language. Things like anonymous types
and type inference were also added to support Linq in the first
place, and they too are very welcome side effects.
Click to expand...

I am immersed in a database app right now, and for that, using ado.net makes
sense, and the dataview gives me most of what I want and need. Its all show some
grids, modify some data, save it to the server, run some reports.

I do like the idea of doing queries on other collections as well, though. I can
handle the verb-last backwards SQL, I have seen enough variations of SQL by now
anyway. My impression of the W*F business is also that it is a lot of WTF
business - Smackdown captures it well. :) The next big project, if this one
ever gets done, will be much less database, and many more classes, and by then
LINQ should be version 2. Sounds like fun.
 
Back
Top