[paulluuk]

I think it's also good to mention that actual production code is _rarely_ ever about being optimal. Making something that actually works, can be easily understood, and rarely ever breaks is much more important in almost all cases.

There are of course performance requirements for almost any project, but whether your service requires 1 ms or 3 ms in production matters a lot less than whether or not your colleagues can actually understand your code.

[xphos]

I think it's miss leading to think optimization is about cut a Ms or two. The only realistically important optimization is bring you big O down. That and understanding when big O doesn't matter for your problem size.

As a c dev one of the biggest mistakes I see is some optimizing to get better instruction generation but using shifts instead of divides or things of that sort. If you optimizing like that you probably spent more compute time optimizing than your optimization will ever safe. Plus like the complier in C at least handles that for you.

[codeflo]

> That and understanding when big O doesn't matter for your problem size.

For example, an extra factor of log(n) is hardly ever relevant, constant factors are almost guaranteed to dominate there.

On the flip side, people are also sometimes surprised to see how quickly an n^3 algorithm becomes infeasible even for very modest data sizes.

[vouwfietsman]

There's a lot more than big O, like data layout, simd, parallelism, cache efficiency, caching, allocation, data architecture, IO efficiency etc etc. And these are just the ones I know about, I bet there's many more.

For improving performance of larger pieces of code often times it's not really important to talk about big O, but much more about how the data is transformed through the system, how lookups are done in memory, how operations are composed together. Then look at what would be possible in an ideal version of the code, and work towards that in steps. This approach can have orders of magnitude improvements, without changing big O.

If you're starting from scratch, this is much easier. Simply never make your code slow :-)

[paulluuk]

> The only realistically important optimization is bring you big O down. That and understanding when big O doesn't matter for your problem size.

Of course, understanding big O is still very important and being able to apply it to real-world problems instead of just online code puzzles is even more important.

But I think it's importance is a bit exaggerated in the coding community, when there are arguably much more important skills for engineers such as building good relationships with your colleagues, knowing when to cut corners to get work done on a deadline, and knowing how to negotiate salary and promotions.

[dafelst]

Especially in games, the difference between 1ms and 3ms is huge. So perhaps the code doesn't need to be optimal, but ideally it is optimized.