| That Big-O thing is mostly theoretical. Most useful application is job interviews. It might stop you from doing some things, like bubble-sorting 1GB datasets, or inserting many elements to the start of a large array. However, in other cases it’s just fine to bubble-sort (for very small collections), or insert many elements to the start of the array (when you’re reading much more often so the profit from memory locality while reading outweigh the losses from relocating those elements while inserting). Modern hardware is extremely complex. No amount of knowledge will help you to 100% predict the performance effects of your changes. Two advices. (1) Learn to profile your code. Both externally, using a sampling profiler that will tell you where’re you spending the CPU time, and internally using e.g. std::chrono::high_resolution_clock that will tell you the performance effect of your changes. (2) Don’t forget about rollback feature of your version control, and don’t hesitate using that as necessary. I routinely discover some of my changes I viewed as performance optimizations actually decreased performance. The reasons include branch misprediction, compiler optimization issues, cores competition for L3 cache, RAM bandwidth, thermal issues… |