views:

244

answers:

2

I am refactoring an existing VB.NET application to use Linq. I've been able to successfully get it to work, but it takes ages (over a minute) on the client machine!

They have lots of rows in the database table, but the old version of the programme on the same machine (which uses Datasets) takes 5 seconds.

My Linq queries are pretty standard, like so:

Dim query = From t As TRANSACTION In db.TRANSACTIONs _
where t.transactionID = transactionID _
select t

They only ever return one or zero rows. Any thoughts?

+1  A: 

I am surprised by the huge time differential (5 seconds to 60+ seconds). I guess it would depend on how complex the TRANSACTION entity is. LINQ to SQL will process each row from your result set and turn it into an object, then add some state-tracking information to the DataContext. A DataSet simply stores the data raw, and processes it into strongly typed data as you read it from the DataTable. I wouldn't expect L2S to incur a 12-fold cost increase, but I would expect some increase.

jrista
TRANSACTION is pretty massive, and I'm only using ~10% of the fields so I've cut the datacontext down so it only uses those fields. Let's see what happens.
calico-cat
I'm unfortunately connecting to an external DB that is an entire accounting program denormalised into one table called TRANSACTION. It's pretty hideous.
calico-cat
Ouch. Yeah, I would work on whittling down the entity to that it brings in only the fields you absolutely need. If its a gargantuan table like that, the bottleneck is transforming records to entities, and sticking each entity in the change tracker.
jrista
The asker said that "They [the LINQ query] only ever return one or zero rows." If that's true, I doubt that's it.
JulianR
Given his question and two comments, the value 't' is an entity (and apparently a monstrous one...db-in-a-table), not a one or a zero. To get a one or a zero, you would need to 'select t.SomeIntegralValue'
jrista
A: 

The code you've pasted doesn't actually access the database at all -- what you do next with 'query' will determine how much data ends up getting transferred to the client. Is it possible something you're doing later on is causing the LINQ version to download more data than the Dataset version?

I have done the same transition on a project and seen only equivalent or better performance from LINQ but there have been instances where the LINQ version was doing a lot more roundtrips to the server, e.g. doing a Count() followed by a fetch of the data as two separate server queries. I usually solved this by doing a .ToList() to get the data locally before working on it. You have to use SQL Profiler sometimes to find out what is going on behind the scenes.

Nestor
Right, it's just a For Each loop copying the data in about 6 fields from the LINQ object to a local object. Nothing fancy.
calico-cat