Why bother identifying the critical points of a program first before optimizing? Doesn't it make sense to implement each function as optimally as possible from the beginning?
Software development is a continual trade-off between productivity and available resources. In the real world, optimization is always a conscious choice - every minute you spend making code run faster is one minute less you have to develop new functionality or fix bugs. Of course, there's a natural balance that all developers strike as the minimum level of optimization they achieve while writing new code, but the general principle is that you should write it to be clear and correct first, and only think about optimization after you've achieved the first two (unless certain optimization parameters are actually part of the functional requirements of the system, such as for real-time or embedded systems development). Part of the reason that this rule of thumb works so well is that, in general, 90% of the run-time of any piece of code is taken up by 10% of the instructions (some would say it's an 80/20 split, but I've found 90/10 to be closer to the truth). Therefore, unless you know you're working on the 10% of the code that takes up all the time, there's literally almost no point in optimizing code - your time could be much better spent making the code clearer (better data structures, better documentation) and more correct (more unit test coverage, more statement coverage testing, etc.).
Further, the phrase "as optimally as possible" is a bit of a rabbit hole; there's almost no end to how much more you can optimize code (to the point of implementing elaborate caching schemes, enabling massive parallel computation on a grid, writing machine instructions directly in assembly language, etc.). Usually, extreme optimizations make the code less clear and maintainable - and sometimes (by accident) even less correct. So unless there's a palpable reason for a higher level of optimization in any given case, it's better to go with the clearest and most easily-maintained approach, and then optimize in the context of careful experimental profiling.
The best thing you can have, of course, is a CLEAR picture of what your real-world peak load conditions will be. If you need to support 10,000,000 simultaneous users, figure that out up front and get some load testing in place that'll actually give you real-world results to play with. Do NOT wait until the peak load hits to "see how it goes" - that is a recipe for failure every time (believe me, I've been there).
