Optimize for developer cycles, not CPU cycles

Performance in software development matters less than you might think. You're almost certainly wasting significant CPU cycles and memory for no good reason—in parts of the codebase you don't intentionally monitor.

Example: binary vs textual encoding

Today, I spoke with a fellow developer who argued that binary encoding is faster than textual. He isn't wrong! Binary encodings mean less work to the CPU. The talk was about an application that received messages of around 100 bytes once a second from around 20 to 30 IoT devices (not becoming more in the foreseeable future) via MQTT.

For today's PCs (2023), that's a piece of cake—even for the weakest ones. The application does more than receive those messages, but the processing load is still trivial.

The more significant drawback is that binary encodings lack many standard tooling options. Look at all the standard UNIX utilities like sed, grep, cat, and many more that you lock out of your toolbox with binary encodings.

You lose the inspectability of messages and network traffic with tools like Wireshark when things go wrong or you need to find bugs. When a stream of data is text, you can often look at it and make sense of it. This isn't true for binary data. UNIX has the philosophy "text is the universal protocol" for good reasons.

Takeaway

Optimize for developer performance, not hardware performance! Since developers are far more expensive than CPU cycles in most scenarios, when you spot bottlenecks, profile the application to identify the true cause. Avoid uninformed, gut-feeling refactoring to make code faster!

So stop thinking about performance beforehand! Every time you feel the need to write the "fastest" solution or introduce some "clever" pre-calculated variables, think twice!

Modern software development advice—what many consider state-of-the-art—strongly advocates against premature optimization. Despite this, it's impressive how these performance discussions with colleagues never vanish, and likely never will.

Disclaimer

I still catch myself wanting to "optimize" where there's nothing to optimize (for now). Knowing this feeling and being able to suppress it, I consider myself healed from the "premature optimization" disease.