Speed is the feature

Taking real time screenshots using api.microlink.io, from 15s to ~900ms.

We love fast software, at all levels: as instant as the software is, a better perception of engineering quality we have.

However, speedy software isn’t a feature you can add in a product sprint. It’s a constant mindset, and the only way to achieve that is going fast slowly.

But how to constantly improve something that constantly change?

If you want to write fast software, use a slow computer Dominic Tarr.

There are a set of things that never – or rarely – change, being anticipation the key to performance.

Understand where your code run

Yeah, I know, it sounds very obvious, but most of us, as programmers, think code and infrastructure are separate things, while they are very linked.

It isn’t the same run an interpreted language vs. compiled languages.
It isn’t the same run inside virtual container vs. host filesystem.
It isn’t the same run a CPU intensive vs. memory intensive software.
It isn’t the same scaling vertically vs. scaling horizontally.

In fact, if we want to think where physically the software is running, the differences are even more obvious.

From Systems Performance at Scale.

Understand what your code does

The smarter way to improving software is by identifying the slowest part that is being used more time. Then the speed up will have a significantly higher impact than improving other minor software aspects.

That’s is known as Amdahl’s law.

If you want to be fast by default, you need to understand what is running under your software:

Are you using network resources? Where are the network resources living?
Which is the network policy? How are you sending the data throughout the network?
Where are you storing your data? Do you need to keep all the data?
Do you need to retrieve all the data at the same time?

This a primordial step to identify what feels slow and where slowness comes from.

Choose what to improve is the hard thing, but it makes unnecessary to optimize all the things.

Most common improvements are actually time optimizations: Instead of serving a real time™ – and costly – response, we can say it is OK serving a pre-calculated response but much much cheaper.

They are done every time you:

Use a memoized function.
Setup a shared LRU cache.
Compress repetitive data using gzip/brotli.
Send a 304 Not Modified response.
Use a replica set architecture.

Understand where your code run

Understand what your code does

Bibliography