When to optimize
Optimization changes a program to use less time, memory, energy, or money. It is justified when a real requirement or measurement shows that the current design is not good enough.
The help desk design has now been tested against ordinary and boundary behavior. Use the measurements from Testing program behavior, not intuition, to decide whether any part of it needs to change.
A sensible order
- Make the behavior correct.
- Make the design understandable.
- Measure the actual bottleneck.
- Choose a focused change.
- Test that behavior remains correct.
- Measure again.
An algorithm with better Big O may be worthwhile for large inputs, but complexity is only one part of the decision. A faster design may use more memory, impose stricter data requirements, or become harder to maintain.
When not to optimize
A simple O(n) scan is often the right choice for a small collection. Replacing it with a complicated index or cache can increase bugs without improving the user experience. Do not optimize based only on intuition or on a theoretical comparison that does not match the real workload.
The goal is not maximum speed at any cost. The goal is an appropriate balance of correctness, clarity, resource use, and user needs.
Do not replace the report log, dictionary, or queues because an alternative sounds faster. Measure the affected operation, make one focused change, rerun the behavior checks, and compare the result. If the requirement changes, begin the reasoning sequence again at the problem definition.