What should I look for when improving performance in Java?

Question

I work in the maintenance team of a big project (around 7k+ classes) and my daily work is mainly to fix bugs. Sometimes, though, I have no bugs to work in. When this happens, I spent most of the time looking for performance gaps in the code. The fact that I have more than 7 thousand classes to look in means it's not obvious to find these gaps.

So I'd like to know what simple things should I look for when trying to improve the performance of the system?

I'm not asking about specific code techniques, but general ones. For example:

• I already looked for all occurrences of code like String a = new String("") and changed to StringBuilder a = new StringBuilder();
• I already changed all the access to the database, where applicable, to use PreparedStatement
• All of the Debug logging were removed, and the Finest ones were removed when possible

As you can see, those changes could easily be made because they do not require measuring the system performance -- the only thing I needed to do was using the search tool inside Eclipse.

Answer 1

Laudable goal, but you need to focus on the actual demonstrable performance problems -- not where you 'think' the performance problems are.

Spend time in a profiler to find the real issues...then go from there. Otherwise you're just churning code without any way of knowing whether you're making a measurable impact.

Even if you had a list of "things to change without measuring system performance" would you really trust them to be right for your circumstance?

In your situation I would suggest you spend time building test harnesses/performance instrumentation so you can see where to get the most bang for your buck.

EDIT: To address the downvote(s) and sentiment about "I know using a PreparedStatement is faster" -- rather than asking for silver bullets, a better question to ask when faced with this issue is "how should I most productively spend my free time to make things better?" The OP clearly wants to improve the situation -- which is great...but without measuring "where it hurts" he's literally shooting in the dark. Is a PreparedStatement faster? Sure -- but if the real performance gremlin is in some other spot, why spend time 'fixing' the DB code when you could make a REAL impact by going after the actual points-of-pain?

One other thing: in a stable system such as the OP is describing, making code changes without good quantifiable justification is often considered bad practice, due to the risks introduced. In such stable systems, the question of risk/reward is for ANY code change must be considered. The risk is significant: many "simple, couldn't break anything" changes have slipped release schedules/introduced major problems. The reward? Uncertain, since you don't actually know if your change was responsible for a performance gain. Hence, we profile to make sure we're improving code which matters.