The value of optimization

One of the things I value the most is optimization, whether it be a website, a native application, or an algorithm. Behind an optimized program, there are people who care about understanding the use case, how it works, and taking care of their product. And I love that.

It is not always necessary to optimize things, in most cases today doing something "normal" is fast enough (the term "normal" is subjective and can vary from person to person). In general, when you do something simple, straightforward, and scoped, it tends to go quickly, and when a product looks polished, it is more appealing from a consumer's point of view.

The problem usually arises when suddenly your website has more traffic, when your product needs to analyze more data, etc. This is when you see if you have taken care of the schemas of your database, the modeling, the indexes, the calls of your source code, the data structures... or even if you have added over-engineering, but I will leave that for another post.

In computer science, this is known as "big O notation", which indicates how fast an algorithm is (or how much space it needs) depending on the size of the input. Here, an O(n^2) algorithm can be fast for a small input, but as the input grows, the time or memory skyrockets.

Last week I solved the billion line challenge (to perform a "map-reduce" on a 14GB file with 1,000,000,000 lines), and in my case, using Go, I was able to optimize it "easily" (easy because I have been interested in the world of optimization for a long time) to 3.5 seconds (and mind you, there are people who know more and it can be further improved). Initially it took 140 seconds.

It had been a while since I had done these challenges. It made me reflect on the "relativity" of time, since for us 1 second may seem fast, but 1 second in CPU time is a lot of operations: if a CPU has a frequency of 3GHz, this is equivalent to 3,000,000,000 operations in a second (approximately).

When I then access a website and it is slow, it takes a long time to load, or I download a "native" application (in reality, it is usually a chromium-based browser in many cases), I wonder what is going on in the servers (or in the code) behind it.

In addition, a slow product can have different consequences:

• Today's society is used to the immediate. This can lead you to lose customers, and therefore, money.
• If you have to scale your service it will cost you more: on the one hand you will need to spend more money on servers, and on the other hand you may find limits that are difficult to fix quickly.
• The image that something slow gives today is usually not good.

Amazon loses 1% of conversion for every 100ms that its website takes to load..

In conclusion, I simply want to emphasize that it is relatively easy today to perform computations that are fast, but at the same time, it is very easy to forget it and if you do not take care of your product it may end up being slow. And this is usually not a good thing, since in the end you will be aware of the opportunity cost in one way or another.

That's why I value products that are taken care of and that are fast.