Java Best Practices – String performance and Exact String Matching | Hacker News Reader

Java Best Practices – String performance and Exact String Matching

javacodegeeks.com

39 pointskioub8 comments

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"))

Yes, you avoid NPE, but consider this piece of code:

  //fetch the name of bacteria from somewhere
  String bacteria = getBacteriaName();
  
  if("botulinum".equals(bacteria)) {
    //do something
  } else {
    //do something else
  }

Now, if for any reason the getBacteriaName() method failed and gave you a null instead of some string, the code will end up doing whatever it is you want it to do if the bacteria name is other than "botulinum". But this might not be what is really desired. The method failed and this should be taken into consideration. The string bacteria doesn't contain the name of some other bacteria, it's null. The problem here is that, under the circumstances, perhaps the code should have returned 'botulinum' but since the method failed, the program acts as if another bacteria name was fetched instead of throwing an exception. Just something to be careful about.

Folks might also be interested in the PMD string checks:

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

And checkstyle: http://checkstyle.sourceforge.net/config_coding.html#EqualsA...

nice practice, really useful! thanx!

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.

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 ;)

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

Reply on news.ycombinator.com