Recently our reporting software, NewRelic, alerted us that some of our code was running slower than usual:

The graph depicts a dramatic decrease in performance on October 11.

I was able to trace it back to a recent update where, in order to make our code more flexible, I began to register and accept default values for various database settings:

New code to allow us to easily register default values for settings that have not yet been set.

Surprisingly, this added up to a palpable slowdown.  We have tons of options in our Apple Fritter theme, hundreds actually, so running this routine potentially hundreds of times per page load was turning out to be a drag.  Here’s what we’re doing now instead:

(Click the image to enlarge) If the value has not yet been set, we’ll actually set it to the default, instead of merely using the default.

See the difference?  If the value has not yet been set, and a default is available, I’ll use the default to set the value.  Therefore, in the future, we never have to go through the routine of locating the default value.

Front-end database writes like that are generally a bad practice.  To write is more expensive than to read.  But in this case, the database write is merely a gambit:

A gambit (from ancient Italian gambetto, meaning “to trip”) is a chess opening in which a player, more often White, sacrifices material, usually a pawn, with the hope of achieving a resulting advantageous position.

I’m paying a one-time penalty to never have to read the default value again.  You can see the subsequent reporting in NewRelic:

The original decrease in performance, followed by an even worse one, followed by restored performance.

Notice the spike in load time, followed by the dip.  The spike occurred on the first few page loads after I allowed for front-end database writes to populate a value.  After that, things actually accelerated to faster than they were before!