Good strategies
Besides the mentioned basic laws of optimization (measure, don't optimize if not necessary), and although the question explicitly asked for efficiency, I always refactor such code during my inspection.
Typically code with bad performance is also badly documented. So with the refactoring I make sure the code is better documented by itself and easier to understand. That's the base for being sure I know what I'm optimizing (as in most cases the requirements for that piece of code will also not be completely available).
When to stop
With a really bad performing application, you will typically have a spike in the runtime shown for a single method (or set of related methods) in your profiler, showing a programming bug or design flaw. So I typically stop if the runtime of profiled methods is distributed mostly equally (or if the majority of bottleneck methods shown is platform code, like Sun Java methods). If further optimization is demanded by your customers you will have to redesign larger parts of the application instead of optimizing existing code.
