Today I found this post published 11 years ago.
Since then many things have changed like PHP 7 and many performance boosts in subsequent releases. I was wondering how statistics would look like 11 years later.
Of course, I don't expect big changes because an underperforming algorithm is a bad algorithm in any language.
I see a lot of developers from time to time abusing of loops and array_shift/unshift and that reminds me the importance of not forgetting about dynamic programming and about what we learned in the university.
Functional languages like Go encourages developers to do that, that's why it's so simple. It doesn't even have an in_array function, so you are aware of the impact of your decisions.
Now in the microservices era, that has become even worse because the O complexity relies now also in nested calls to different services APIs and sometimes that means combining the results into big JSON payloads.
Recently I faced a case of a poorly written API endpoint that was paginated but for every item it was calling another service. As soon as the UI released the feature to change pagination size to 20, 50, 100 you can imagine what happened when users selected 100.
Conclusion: Big-O problems are not only happening in the scope of the program itself, but also can happen in the communication between services.
Let's just be more aware that pagination or using the "standard lib" or native language code doesn't always mean better performance in an implicit way. Let's always have the O notation in mind.
Recommended reads: