Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I saw on a article that put forth this statement:

Developers love to optimize code and with good reason. It is so satisfying and fun. But knowing when to optimize is far more important. Unfortunately, developers generally have horrible intuition about where the performance problems in an application will actually be.

How can a developer avoid this bad intuition? Are there good tools to find which parts of your code really need optimization (for Java)? Do you know of some articles, tips, or good reads on this subject?

share|improve this question
This comes down to "How do I avoid [relying] on intuitions [when making decisions]?" Simple: you verify with hard-facts and data. So, in the case of optimization, from a developer's perspective: you benchmark. –  haylem Aug 24 '11 at 13:41

7 Answers 7

up vote 38 down vote accepted
  • Use a good profiler to identify expensive methods.
  • Document how long the hot spots actually took.
  • Write a faster implementation of the hot spots
  • Document how long the hot spots now take, hopefully not making them hotspots anymore.

Essentially you need to be able to prove to others where the problem was, and that this change made it go away.

EDIT: Not being able to prove an improvement, qualifies - in my personal opinion - for immediate rollback to the original version.

share|improve this answer
Or to put it even more simply: "In order to avoid bad optimization intuition, don't use intuition. Measure." –  Kyralessa Aug 22 '11 at 18:06
That's why yours is an answer and mine is just a comment. :P –  Kyralessa Aug 22 '11 at 18:21
@Thomas, if you fiddle with readability and maintainability you ain't exactly looking at performance problems, are you? –  user1249 Aug 24 '11 at 12:01
@Thorbjørn Ravn Andersen What I'm saying is if you make a change to improve performance, regardless of if the performance increases, decreases, or remains the same, as long as it is within spec, you need to consider factors that can't necessarily be quantified before deciding if you need to roll back the change or not. You shouldn't make a change based only on performance, unless it breaks the requirements. It's hard to prove readability or maintainability changes in the same sense as it is to prove performance changes. –  Thomas Owens Aug 24 '11 at 12:10
@Thomas, I disagree. Even within spec, you need to retest the new code thoroughly. This is not needed for the old code. Revert. –  user1249 Aug 24 '11 at 13:31

The only way to know where to optimize is to profile your code. Instead of making changes that you think will provide a benefit, know for sure where the worst-performing code is and start there.

Java makes this pretty easy with the VisualVM tool, which has been bundled with recent releases of the Java Development Kit (JDK). The idea is to find out which methods are called the most and in which methods you are spending most of your time, both in your code and in external libraries. You can also get performance data on garbage collection so you can tune your collector and adjust min/max heap space required by your application.

share|improve this answer
VisualVM is not in the JRE, only the JDK. –  user1249 Aug 22 '11 at 15:52
@Thorbjørn Ravn Andersen Good call. I should clarify. However, if you are doing Java development, you usually have the JDK installed (although you might be running the OpenJDK or similar - I don't know if those come with VisualVM). –  Thomas Owens Aug 22 '11 at 15:53
I very frequently switch workspaces in Eclipse which then defaults to the JRE which launched Eclipse. As it is much easier to install JRE's than JDK's we have slowly migrated to an ant build process which includes the Eclipse compiler and therefore can run on the plain JRE. Hence, these days you can actually do real work without the JDK. VisualVM can be downloaded separately making it easier to use with a given Java versino, as under Windows 64-bit JVM's cannot connect to 32-bit JVM's and vice versa. –  user1249 Aug 22 '11 at 16:53

These tools are called profilers. You can use them to actually measure which part(s) of your program take the most time to execute, so where to focus your tuning efforts.

It is equally important to measure again after the changes, to verify that your changes have the intended effect.

share|improve this answer

As anyone here is talking about profilers I will focus on this part of the question.

How can a developer avoid this bad intuition?

You. do. not. Instead you never optimize early on.
Repeat it again and again and again, as it's a religious mantra.

You will find yourself doing that and will discover you should have not.
And then again.
And again.

Early Optimization is one of programmers' capital sins.

Tools and stuff are part of the later optimization which is an established craft.

share|improve this answer
Early "convoluted code" optimization, for sure. Chjoosing algorithms and/or data structures that fit your problem and (with your expected processing load) have good performance characteristics is something that should be done before you start writing code. –  Vatine Sep 15 '12 at 20:10
@Vatine Yes, been there. No, just don't. Do what fits your mind-map of the problem at hand. It could be the most performant algorithm, and I wish you that, it doesn't have to. –  ZJR Sep 15 '12 at 21:15
it sounds to me as YAGNI principle - You Are NOT Gonna Need It ! –  Yusubov Oct 4 '12 at 2:26

Look also at how much memory your program uses, not just its speed or runtime.

Lots of coders who work with garbage-collected languages such as Java are under the mistaken impression that garbage-collection prevents memory leaks. That is not the case. If you hold a reference to an object you don't need anymore, it won't get collected, and so it will leak.

I have seen Java web applications that were so leaky that they would run their server out of swap space!

If you use both a runtime profiler and some manner of memory profiler, you will learn to write faster and leaner code intuitively. This has the effect that your code is more likely to run fast on the first try.

share|improve this answer

my remedy is to start by getting clear answers to two questions:

  1. how to measure performance (eg. measure data load time)
  2. what is the target value (eg. data loads in 3 sec or less with 95% confidence)

Learned above trick from tiger team guys who were once invited to save a broken release of our product. That release was broken for performance reasons, it could make company loose strategic customer which justified tiger guys involvement (pretty expensive btw). I was assigned to assist them in clarifying project details; also used this as an opportunity to learn a bit or two about performance.

share|improve this answer

What I've found is the best antidote to premature optimization is this method.

Once you've used it to speed up some code (as in this example), it becomes an addiction of its own, and you understand the first principle of performance tuning isn't tweaking code, it's finding the problem.

Real optimization is to premature optimization as hunting to feed your family is to shooting tin cans. It's all about finding the quarry.

share|improve this answer
And unfortunately, you can only carry 200 pounds back to your family, so don't shoot squirrels all day. –  Jordan Aug 25 '11 at 7:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.