DMGPerformance Improvements
There are a few basic tools that every programmer must become proficient in to be really good at his/her work: editor, compiler, version control, and profiler.
In my case, my profiler told me that I was making several hundred individual calls to the database to retrieve all the data on my blog's main page. That's why performance has been in the weeds here for a while.
In my defense, I made a conscious decision to write the software that runs this site without thinking about performance. I tried to avoid the obvious, crashing blunders, but otherwise just kind of did things in whatever way made my work easy and kept the code simple.
I still believe that was the right decision. See, simple code is maintainable code. Simple, well-structured code is easy to change when the need arises.
And by optimizing for performance early on, I would have spent lots of time dealing with the consequences of that optimization rather than adding new features. It's a natural part of a program's lifecycle to reach a point where performance is a problem and some restructuring is in order. If you've done everything else right up until that point, fixing performance issues is a breeze.
In my case, I was making about 10 database calls for every blog entry displayed. On my front page, that's 5 main entries displayed front and center, plus up to 10 more in the "recent comments" sidebar. Several other spots are going to get some attention soon, but it was pretty clear where to start.
My profiler also told me that the query that finds the "recent images" for the sidebar was taking a while to run. It has to search the table based on the Date_Posted field, and I never bothered to add an index to that field. Doh!
So, I've added the index, and changed the database access code so that I now retrieve just the header information for blog posts on the front page, and things are once again pretty snappy. I'm still making too many database calls, but it'd down from hundreds to around thirty or so.
Which brings me to my last bit of advice about performance: when it is acceptable, stop working on it. Once nobody notices any slowdown, speeding things up does not add value to the project, and tends to make the code less maintainable, making the operation a net negative. I'm certainly going to make some adjustments in the future, but, but only as I have time. Working on my website code is pretty far down my priority list.