John,
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.
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.
Am I missing something?
Thanks
Sent from my phone
On Nov 6, 2013 8:21 PM, "John Rose" <john.r.r...@oracle.com> wrote:
> On Nov 6, 2013, at 11:30 AM, Peter Levart <peter.lev...@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.
>
> — John
