Strange performance outcome, I have a LINQ to SQL query which uses several let statements to get various info it looks like this
public IQueryable<SystemNews> GetSystemNews() { using (var t = new TransactionScope(TransactionScopeOption.Required, new TransactionOptions { IsolationLevel = System.Transactions.IsolationLevel.ReadUncommitted })) { var results = from s in _datacontext.SystemNews let member = GetMemberInfo(s.MemberID) let determination = GetDetermination(s.DeterminationID.Value) let daimoku = GetDaimoku(s.DaimokuID.Value) let entry = GetEntry(s.EntryID.Value) let encouragment = GetEncouragement(s.EncouragementID.Value) select new SystemNews { NewsDate = s.NewsDate, MemberID = s.MemberID, PhotoID = s.PhotoID.Value, DeterminationID = s.DeterminationID.Value, DaimokuID = s.DaimokuID.Value, EntryID = s.EntryID.Value, EncouragementID = s.EncouragementID.Value, Member = new LazyList<Members>(member), Determination = new LazyList<Determinations>(determination), Daimoku = new LazyList<MemberDaimoku>(daimoku), Entry = new LazyList<MemberEntries>(entry), Encouragement = new LazyList<MemberEncouragements>(encouragment), IsDeterminationComplete = s.IsDeterminationComplete.Value }; return results; } }
I created the same thing (basically at least the various info that is obtained in this) into a SQL View, and the LINQ to SQL returned results in under 90 miliseconds where as the view returned the same data actually less info in over 700 milliseconds. Can anyone explain this?
In general, LINQ-to-SQL will be ‘about the same’, and I’d agree that caching is porbably an issue here. Really you need to look at the generated SQL; the easiest way being:
Then try running the TSQL directly in Query Analyzer. SPROCs have some advantages in terms of being able to optimise access, use table variables, etc; however, LINQ has the advantage of composability – i.e. you can apply your paging, sorting, projections, etc in the single query. You can at a push do that with an SPROC, but it is very hard work.
But really, the key is in looking at the TSQL; it might be that you haven’t loaded all the data, for example (lazy loading).