Vandaag ben ik veel interessante artikelen tegen gekomen op het internet. Een daarvan is een LINQ to SQL performance test. Blijkbaar had Derik Whittaker wat tijd over en heeft een performance test gedaan met verschillende manieren van de data-access op te bouwen. Het volledige artikel is op z’n weblog te lezen: https://devlicio.us/blogs/derik_whittaker/archive/2008/03/14/playing-with-linq2sql-and-various-performance-tests.aspx

Z’n conclusie is dat wanneer je een generieke DataContext gebruikt in je code, je enorm veel performance verlies hebt. Het hoe en waarom is hij nog niet achter, maar de uitvoer is ongeveer 7x langzamer dan wanneer je een ‘goede’ DataContext gebruikt.
In dit bovenste voorbeeld wordt een generieke DataContext gebruikt, de tweede een specifieke welke alleen voor de betreffende tabel kan worden gebruikt.

DataContext db = new DataContext(new SqlConnection(connectionString)); 
IEnumerable sports = from s in db.GetTable() 
select s;

SportsDemoDataContext db = new SportsDemoDataContext(new SqlConnection(connectionString)); 
IEnumerable sports = from s in db.Sports 
select s;

Na 10.000 keer de query uit te voeren blijkt dat het 2e voorbeeld met een gemiddelde van 13022 miliseconden wordt uitgevoerd en het 1e voorbeeld met een gemiddelde van 78042 miliseconden wordt uitgevoerd.
Een behoorlijk verschil dus. Zelf maak ik ook gebruik van zo’n generieke DataContext uit het eerste voorbeeld. Dit omdat je dat mooi in je Base.cs kunt opnemen. In de eerstvolgende performance-tuning update zal ik dit aanpassen zodat iedere klasse z’n eigen, juiste, DataContext krijgt.
Het is toch mooi dat sommige mensen hier de tijd voor nemen om te testen. Zelf zou ik dat namelijk nooit doen, maar ik doe er wel weer m’n voordeel mee.