hg: jdk8/tl/jdk: 7194897: JSR 292: Cannot create more than 16 instances of an anonymous class; ...
john.r.rose at oracle.com
Thu Nov 7 01:20:39 UTC 2013
On Nov 6, 2013, at 11:30 AM, Peter Levart <peter.levart at gmail.com> wrote:
> Well, indexOf(char) or lastIndexOf(char) searches for a single char. We can do better searching backwards for two chars at the same time.
> If the "name" of VM-anonymous class is always ending with pattern: "slash followed by some decimal digits" then the following would be even faster:
Although this reasoning is plausible, it is not a reliable conclusion, and should not drive edits of Java code without careful measurement. The reasoning assumes a performance model based on the interpreter and bytecode count. But performance depends on native code produced by the JIT.
An optimizing JIT will usually transform the code deeply. For string scanning, for example, HotSpot has an intrinsic for String.indexOf(String) that uses totally different code from a user-coded loop. (It is not currently so for String.indexOf(int), but String.indexOf("/") is potentially very fast.)
Also, with your example code, the combined loop may often be faster than two back-to-back loops, but simpler loops can sometimes be vectorized more robustly, to the point where back-to-back simple loops, if vectorized, may be competitive with a hand-fused loop.
So loop complexity and method intrinsics can create surprises for those who rely on simple performance modesl
Some day we will get to a world where loops are specified stream-wise, and robustly optimized without this sort of manual intervention. In the mean time, be careful about advising hand-optimizations of Java code. They can backfire, by confusing the JIT and preventing optimizations that would apply to simpler code.
More information about the core-libs-dev