My Bad Coding Habits, Thanks LINQ to SQL!
(
Jun 05 2008 - 08:19:17 PM by
Timothy Khouri) - [
print blog
post]
Don't Forget Performance!
I have to start off by saying that I'm not seriously blaming LINQ to SQL for my bad coding habits, but I will mention that due to all these great technologies that just do stuff for us, we sometimes forget to check for things like performance. Sometimes I take for granted that .NET is ultimately just running code that some mere mortal programmer wrote.
As a result, I just assume that anything that happens outside of *my* code will run at infinite speeds. So, the other day I was reprimanding (not really, but I was semi-lecturing) one of my senior developers for hitting the SQL server in a for loop. Now, to be fair, he's new to LINQ to SQL, and didn't realize that this...
foreach (Task t in myTasks) {
if (t.BillingEntries.Count() > 0) {
}
}
...was going back to the database over and over again :) Just for clarification, the "BillingEntries" property up there is linked from another SQL table.
It wasn't difficult to fix the problem. All we needed to do was get the "count" information in a single hit to the DB, store it in a dictionary, and use it in the for loop, instead of hitting the DB in the for loop.
Where I Had To Eat My Words
So, yesterday, as I was updating some styling on the site (SingingEels.com), I realized that some pages were taking a long time to load (from my local machine). A few pages were taking upward of 10 seconds each... and that's when I realized!
My web server and SQL server are physically next to each other (I think in Colorado, USA), but I live in Florida. So, when I was developing locally, and my web app hit my SQL server in a for loop... well, you get the idea.
Needless to say, I've since then been optimizing the site, and I've included a "server load time" number at the bottom of the site. The moral of the story is, don't forget to check your app for performance issues.