Turn over the big rock first

Leave no stone unturned. 

We all love writing optimized code, it can bring us so much joy, but if we follow the idiom aforementioned, we can fall into a dangerous trap.  When it comes to optimizing for performance, it’s often better to just turn over the big rocks.  Let’s look at a few common rocks we don’t often look at and let’s make sure we turn these big ones first before looking to find which array method is faster, map or for….in, etc.   These rocks are language agnostic and just good things to think about so you can write for performance.

Big Rock 1) Get only the data you need

This seems like a super obvious performance tip, but I find very often that developers end up getting more data than needed.  If you are displaying a user’s name on the screen, be sure you are pulling only the name from the database and then returning only the name to the front end.  Remember if you are writing a query and you do select *  then zombies will attack you in your sleep.  

Big Rock 2) Loop over only the data you need to

Again, super obvious right? What I see happen with this rock all too often is that we reach for and loop over a collection when we don’t need to.  Whenever you find yourself reaching for a loop construct in whatever language of choice you are using today, first ask yourself can I do what needs to be done without looping at all.  I think you will be surprised at how often this is the case.  After you have determined a loop is needed, the next step is to figure out how you can get away with the fewest iterations possible.  Use things like breaks, etc to exit the loop as soon as you can.  The last thing I will say about this rock, is be sure that any code you are performing within the loop has had all its big rocks removed because a slow code looped over will turn your milk quicker than a broken refrigerator on a hot day.

Big Rock 3) Log only what’s needed.

There is disagreement in the community of how expensive logging is.  This is one that you need to measure and see with your stack just what writing to logs can save you performance wise, but from what I have seen, writing to logs can be a sneakily expensive operation.  Some big mistakes I have seen made here are not that writing to the log is all that costly, but it is what is written that can add up.  Oftentimes we end up serializing large objects which can have large performance impacts.  So my tip when turning this rock is be sure you write only what is needed to the logs and you do your best to avoid expensive operations like serializations when logging.  Also, developers that have the debug log level (or silly, yes most languages have a “silly” logging level) on in production are 13 times more likely to get attacked by a porcupine

Big Rock 4) Uncaught Exceptions

Throwing exceptions tends to be a costly operation in most programming languages, so when I am looking to optimize for performance in a system this is a stone I often look at.  Many times as developers we fall into the trap of thinking our code will never error, or can never error.  Not catching errors can lead to several adverse effects besides performance.  Often raw errors reveal much about our systems that can be a security concern.  Uncaught exceptions also lead to a negative user experience.  So, be sure to utilize try/catch and to bubble errors up to the UI efficiently.  Give as much information as you can to the user to try and correct the problem, and don’t leave it to the language’s exception handling.  A good error goes a long way, but an uncaught exception goes bump in the night.

These large rocks oftentimes can get you to the 80% line when it comes to performance improvements.  There are almost an infinite number of other stones you can turn to eek out more performance from your applications, but be sure you hit the big ones first.  After you hit these big ones, my tip would be to profile your code, find out where performance issues remain, and work to optimize those.  Measure what you change and be proud of yourself when you make things more optimized. Iterate and improve.  It is one of the joys of programming.