How Smart is the Java Compiler?

[tmiranda]

I have a programming style question that I'd like some feedback on. In the old days I'd have to take great pain to make sure that I wrote code that was optimized. For example, if a derived variable was used multiple times I'd have to make sure it was calculated just once and then reused. Like this:

String longString = someLong.toString();

myMethod1(longString);
myMethod2(longString);

instead of this:

myMethod1(someLong.toString());
myMethod2(someLong.toString());

I'm assuming optimization has vastly improved and I do not need to do such things anymore. True?

Where can I read about Java optimization so I can understand what code is expensive to run and what code is cheap?

[GKusnick]

Optimization applies only to expressions that are transparent to the compiler so that it knows there will be no side effects from factoring out common subexpressions.

Consider:

myMethod1(stack.pop());
myMethod2(stack.pop());

Would the compiler be justified in "optimizing" this as follows?

String s= stack.pop();
myMethod1(s);
myMethod2(s);

Obviously not, because doing so would change the meaning of the program. But it's not obvious to the compiler that this case is any different than yours. They both involve identical calls to methods of objects. The fact that the method happens to be called "toString" is irrelevant. Unless the language has some formal mechanism for flagging specific methods as purely functional and free of side effects, the compiler cannot optimize out calls to those methods.

[broconne]

Originally Posted by tmiranda

I have a programming style question that I'd like some feedback on. In the old days I'd have to take great pain to make sure that I wrote code that was optimized. For example, if a derived variable was used multiple times I'd have to make sure it was calculated just once and then reused. Like this:

String longString = someLong.toString();

myMethod1(longString);
myMethod2(longString);

instead of this:

myMethod1(someLong.toString());
myMethod2(someLong.toString());

I'm assuming optimization has vastly improved and I do not need to do such things anymore. True?

Where can I read about Java optimization so I can understand what code is expensive to run and what code is cheap?

It may be cliche but in my opinion it is more important to focus on readability rather than optimizing execution speed. If later you find your code is not performing as you would like, then it may be time for some targetted optimizations.

Optimizations items such as inlining, lock elision, etc, may change from release to release, and specially from JVM implementation to implementation.

[tmiranda]

Originally Posted by broconne

It may be cliche but in my opinion it is more important to focus on readability rather than optimizing execution speed.

This is my theory as well. I just wanted to make sure that by focusing on readability I wasn't tanking the performance.

When I look at other people's Java code it is written much more compactly than my code. Sometimes I look and see one line of code and I think if I had written that I would take 3 or 4 (or more) lines. Still being a Java noob I wanted to make sure I wasn't doing something stupid

Thanks.

[david1234]

If it were my code, I'd probably go with option 2. The time required to create the new object, is probably not that much less than just running toString a couple times.

function(whatever.toString());

Lately, about the only place where I do a lot of code shortening is using the ? operator instead of an if-else block.

BigDecimal smallerValue = (value1.compareTo(value2) <= 0) ? value1 : value2;

vs

BigDecimal smallerValue;
if (value1compareTo(value2) <= )) {
smallerValue = value1;
} else {
smallerValue = value2
}

To me, it's just easier to read that the important part of the code is the setting of the smallerValue rather than the actual test of the other values

I think as long as you don't do this, just about anything goes. (people who don't use brackets {} on multi-line blocks should be shot)

if (somebool)
doStuff();
else
doOtherStuff();
movingOnToOtherThingsThatAreNotPartOfTheElse();

[Fuzzy]

Originally Posted by tmiranda

I have a programming style question that I'd like some feedback on. In the old days I'd have to take great pain to make sure that I wrote code that was optimized. For example, if a derived variable was used multiple times I'd have to make sure it was calculated just once and then reused. Like this:

String longString = someLong.toString();

myMethod1(longString);
myMethod2(longString);

instead of this:

myMethod1(someLong.toString());
myMethod2(someLong.toString());

I'm assuming optimization has vastly improved and I do not need to do such things anymore. True?

Where can I read about Java optimization so I can understand what code is expensive to run and what code is cheap?

The compiler will not optimize this for you. You have to realize that in Object Oriented programming, someLong.tostring may not resolve the same every time. Of course, in this example, it would, but that assumption can't necessarily be made by the compiler. Remember, ToString is not some static transformation. It is, in itself, a completely separate function, that could, theoretically, return something different because of some other factor that may have changed in between those two method calls.

That said, I agree with others here, that minor optimizations like this on modern processors are not exactly necessary. Proper readability will end up with more bug-free, and easier to maintain code, which, in the end, would be better.

[Audacity]

When I'm initially writing code, I only pay much attention to optimization for inner loops.

Aside from that, I'd just go with doing whatever will make your code more maintainable, and then later on when the project is closer to completion (or release) run it through a profiler and optimize the hot spots.

[sdsean]

Ok I'm gonna diverge a little bit here. . .

While I agree the readability is very important. . . I actually think optimizations should at least START at the begining. . . I agree that you will attack this over time, and you may not need to try an optimize as your coding. . . but. . .

In cases like the one above. . .Its both readable, and obvious to only call toString() once. (Granted this is a very simple case). . .but it doesn't take away from readablility in my opinion. . .

The biggest reason I say this for b/c especially when you are dealing with an environment that your code is loaded into, the API's you call will change over time.

So. . .simple optimizations like this one, (where you minmize "." and mimize calls to functions unless necessary), from the start go a long way.

Certainly, your code may still not be fast enough, and you have to keep going. . .but things like I just mentioned I wouldn't necessarily call unreadable, and they can help alot. . . (and also b/c Java, like many other languages, is run in a VM, and is so dynamic).