<p dir="ltr">John,</p>
<p dir="ltr">Just curious here - the String.indexOf(String) will have to fetch the arg string from memory somewhere (how are constant pool entries handled by the way? Is their address patched in or is it a lookup into the StringTable?).   If it's not in cache, that could be tens if not hundreds of cycles.  With char, the search value is an immediate so no additional mem fetches.  For short strings (I'm assuming this case falls into that category) I don't think intrinsic is all that beneficial given that it can miss on memory.</p>

<p dir="ltr">I agree that measurement is needed, but mental model (even taking intrinsic into account) seems to imply that char code would run faster, especially if searching backwards is more likely to terminate loop sooner.</p>

<p dir="ltr">Am I missing something?</p>
<p dir="ltr">Thanks</p>
<p dir="ltr">Sent from my phone</p>
<div class="gmail_quote">On Nov 6, 2013 8:21 PM, "John Rose" <<a href="mailto:john.r.rose@oracle.com">john.r.rose@oracle.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Nov 6, 2013, at 11:30 AM, Peter Levart <<a href="mailto:peter.levart@gmail.com">peter.levart@gmail.com</a>> wrote:<br>
<br>
> Well, indexOf(char) or lastIndexOf(char) searches for a single char. We can do better searching backwards for two chars at the same time.<br>
><br>
> 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:<br>
<br>
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.<br>

<br>
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.)<br>

<br>
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.<br>

<br>
So loop complexity and method intrinsics can create surprises for those who rely on simple performance modesl<br>
<br>
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.<br>

<br>
— John</blockquote></div>