Don't Worry About Performance

It is tempting (and sometimes exciting) to speak of performance in broad, categorical terms. Most of the time, this is done in blanket comparisons that generalize across entire language ecosystems. Node is way faster than Ruby, but it’s no Java. These are exactly the kind of sweeping statements that are impossible to prove or disprove, as they fail to convey enough context for an objective evaluation to be made.

Disproportionate attention to the performance characteristics of a technology is fertile ground for the spread of paranoia, confusion, and fear about one’s choice of tools. This distracts developers from the act of writing software and urges them to spend time worrying about whether a project is being written in a fast enough language or framework. Some will turn to one of the plethora of synthetic benchmark suites or speed comparison sites, most of which have a tendency to show which tools are fastest at tasks most programs will never perform.

The good news is that for nearly any project, the speed of its implementation language is rarely a factor in its ultimate viability.

Whether a project succeeds or fails has much more to do with how well the team building it can identify and conceptualize the right problems than how fast a program can perform arbitrary operations.

More specifically, whether a business succeeds or fails is extremely unlikely to be affected by what language a team selects when building a product.

The development of general purpose programs should be carried out in observance of the following hierarchy of code characteristics. When decisions need to be made that involve compromising one of the elements, the one higher on the list should take precedence.

Code should be:

  1. Intention-Revealing: The code should be easy to read and understand.
  2. Maintainable: The code should be easy to work with.
  3. Efficient: The code should use no more resources than needed.

Only in special situations should this hierarchy of objectives be deviated from, such as a particular operation that takes too long to complete or a hot code path that is used by every operation. In these cases, small surgical optimizations can have disproportionately beneficial returns and should be made. These cases should be exceptional and not the norm. If optimization is needed in many places, there is likely a need for a wider view and an effort to identify systemic issues with the project’s design.