
Java Best Practices – String performance and Exact String Matching - kioub
http://www.javacodegeeks.com/2010/09/string-performance-exact-string.html
======
pittsburgh
Along the lines of String best practices, my favorite is to reverse the usual
order of variable and literal to avoid null pointer exceptions:

    
    
      if("botulinum".equals(bacteria))
    

instead of:

    
    
      if(bacteria.equals("botulinum"))

~~~
tcopeland
Folks might also be interested in the PMD string checks:

<http://pmd.sourceforge.net/rules/strings.html>

~~~
kodablah
And checkstyle:
[http://checkstyle.sourceforge.net/config_coding.html#EqualsA...](http://checkstyle.sourceforge.net/config_coding.html#EqualsAvoidNull)

------
Sandman
Truth be told, I hoped for a bit more from this article. Ok, so now we know
that the indexOf() approach works great on strings with the length of 1150000
characters or less. But at what point do other algorithms start outperforming
indexOf()? In what circumstances (for example the size of the document, length
of the pattern and so on) should I use one algorithm, and when should I use
another?

Shame that the article didn't really answer these questions.

------
rkalla
Another tip for the manual-scanners out there to make that for-loop a little
bit faster:

    
    
      for(int i = 0, len = text.length(); i < len; i++) {
        // do something
      }
    

avoids the method call to length() in the comparison expression every time. I
imagine a lot of you know this, just from time to time I run into someone that
balks at what you can do inside of the old-school for headers and how flexible
it can be to help make your life inside the loop a hair bit easier. (e.g. init
your variable that you want to pull out)

As for this article, was excellent. I was surprised at how robust of a test
suite it was; fortunately it looks like you only need to get concerned with
really robust/complex search algorithms if you are working with large chunks
of text and brute-force is surprisingly fast in most shorter cases.

Chalk one up for raw, unsexy CPU power ;)

~~~
bermanoid
Assuming text is a String variable, the JVM should almost always pull the
length call out of the loop anyways, since length() is merely a getter of the
final 'count' field within the also-final String class (see
<http://www.docjar.com/html/api/java/lang/String.java.html>), and hence cannot
change within the loop, aside from re-assignment of the text variable itself
(which is something that, IIRC, the modern JVMs should notice). In fact, that
type of optimization is _precisely_ the reason that if you want to access
fields from multiple threads you need to perform some kind of synchronization
or mark them volatile, if you don't then the JVM assumes that kind of
optimization is allowed, by default, and it will do it in most cases.

That said, if you're really in a performance critical section sometimes it
doesn't usually hurt to hand-optimize like this, just in case the optimizer
craps out for whatever reason and decides to skip optimizing certain sections
of code (these reasons can be hard to predict).

