Hacker News Reader

Comment by typicalrunt | Hacker News Reader

Java compilers are very poor at lifting constant expressions out of loops. The C/Java for loop is a bad abstraction, because it encourages re-computation of the end value in the most typical case. So for(int i=0; i<str.length(); i++) is three times slower than int len = str.length(); for(int i=0; i<len; i++)

Does anyone know if this is still valid advice? I recall reading somewhere that the JIT has optimized around this problem.

View on HN

For this example, I would expect that any decent Java compiler optimizes this away nowadays. That does introduce a dependency between compiler and standard library, but the benefit is large enough, given that this is idiomatic code, and that Java has it easy here because Java strings are immutable.

For general collections, things are more difficult, but I still expect java to optimize things in many cases. I haven't checked, though.

A C/C++ compiler has a tougher job. It can only move strlen calls out of a loop if it can determine that the strlen you call came from the correct <header> file and that there is no defined behavior under which either the pointer or its contents change inside the loop.

If it cannot do either, it must 'call' strlen each time through the loop (That 'call' can be inlined, especially if the compiler knows it is the standard library's strlen)

The thing with Java is that the compiler (that is, javac) does very little. It will replace constant variable accesses with the value (things that are defined as static final.....) but that is about it. This is why its very easy to decompile Java source, complete with method and variable names.

All the real optimization is done by the JIT which usually doesn't 'kick in' unless a segment of code gets called many times, in client mode I think the default in the hotspot vm is 1500, while in server mode is lower but I can't remember the default. I generally manually set it to something around 200 for sever apps.

As a result of this, the JIT may optimize this loop, it may not, it may optimize in the middle of a test, it all depends on how often the code its called. You can easily get different benchmark results by changing the -XX:CompileThreshold JVM parameter and will see variability in performance unless you 'warm up' the JIT forcing it to optimize.

The thing is String.length() doesn't do any re-computation. All it does is return a variable defined in the String object that is modified when the string it contains changes.

See my other comment saying you should ignore any speed suggestions by the article.

That is correct from the String source I am seeing. It simply returns a field, so the JVM probably inlines it into the for loop conditional making this advice not really necessary.

I like this way to rewrite it when the end test is slow (I think this is correct syntax):

for(int i=0, len=str.length(); i<len; i++)

One evaluation and you don't have an extra len variable hanging around.

Reply on news.ycombinator.com