I can improve throughput by 1000x by putting it on 1000 machines

My app is installed on 10000 phones! See how much better it runs!

And sometimes a co pletely different approach is better than focusing on the runtime of a single piece. We had a system that was sql code that ran many functions that scaled horribly as data was added to the system. Each function was as fast as could be measured, but the process of running them as separate repetitive functions ended up being over 24 hours in some cases.

Redoing them as a single stored procedure and optimizing that reduced it to a few minutes. This approach was much more complex than the individual functions and took about a year to replace what was oroginally written in 3 months.

Many times the effort to make something more efficient takes far longer than getting it to work in the first place, and many processes are slow because they did not allocate time to properly optimize or include staff that are able to optimize.

I think this is the author being humble. jmmv is a long time NetBSD and FreeBSD contributor (tmpfs, ATF, pkg_comp), has worked as a SRE at Google, and has been a developer on projects such as Bazel (build infrastructure). They probably know a thing or two about performance.

Regarding the overall point of the blog, I agree with jmmv. Big O is a measure of efficiency at scale, not a measure of performance.

As someone who teaches Data Structures and Systems Programming courses, I demonstrate this to students early on by showing them multiple solutions to a problem such as how to detect duplicates in a stream of input. After analyzing the time and space complexities of the different solutions, we run it the programs and measure the time. It turns out that the O(nlogn) version using sorting can beat out the O(n) version due to cache locality and how memory actually works.

Big O is a useful tool, but it doesn't directly translate to performance. Understanding how systems work is a lot more useful and important if you really care about optimization and performance.

Itcs a generalized method/notation of measuring how long a piece of code takes to run for a given input.

O(n^2^) means that as the input n grows, it takes exponential time to process. Like if you were trying to find items that matched in an array by looping over every item in the array and then using a nested loop in the first one to compare against every other item in the array. You'd be doing (# of items) * (# of items) comparisons, or (# of items)^2^ comparisons. n^2^ comparisons.

There's some rules about simplifying the result down to the most significant portion, so O^n^+n would be simplified as O^n^, but that's the basics.

It's a pretty important concept as you get into making larger projects.

Its when you find the clitoris for the first time.

Joking aside, it's a description of the runtime of a thing for a size of a data set. Its expressed as a function. So for example an exponential function would get longer and longer as your data set size grows, linear time has a basically proportional operating time compared to the size of the data set, and log(n) would see runtime increase very little as data set size increases.