Comments on Code Instructions: Busting java.lang.String.intern() Myths

Dont forget Matt Quigley, String.equals short-cuts...

2012-01-24T16:12:05.510-05:00

Dont forget Matt Quigley, String.equals short-cuts the comparison with a this==that, then tries a length comparison, then finally tries a == comparison on the char array elements.

William Louth, looking up your cost table for method calls means absolutely nothing when you're running code in a JVM that auto-inlines methods and compiles to native code. Unless you're comparing a large number of identical length strings it would be very rare to enter the loop that iterates the char array.

Another reason why == performs only marginally fas...

2010-08-21T12:44:57.763-04:00

Another reason why == performs only marginally faster than equals() is that String.equals(String) will probably do the == comparison as the first check (e.g. see sun jdk 1.6)

I find it strange that you said "== is 5 t...

2010-06-22T15:38:44.406-04:00
I find it strange that you said "== is 5 times faster than String.equals()" and then right after that said that the myth was busted. It's not a myth if it's 5 times faster! When one considers it in O(n) notation, String.equals() is O(n) and == is O(1); this is not a myth, it's fact.

Furthermore, I guarantee you that it's much more than 5 times faster in many applications; depending on the type of strings and how they are used, it can be many orders of magnitude faster that cannot be ignored.

In any case, to your point, if people don't know why they are using .intern() then they most certainly should not be using it.

Hi, I don't agree with your post. I'm wor...

2010-02-16T14:58:53.767-05:00
Hi,

I don't agree with your post. I'm working in the area on natural language processing. There we do a lot of data crunchings with words and lots of statistics. Let me say that without "intern()" we could go nowhere. It saves our day. Without it, I busted 64 Gb of Ram just because each word made its small nest memory. When you have applications where you must have vocabularies of hundreds of thousands of words permanently in memory, it helps a lot. As I said, you couldn't do anything without it ...except mapping them to integer ids and going on with the integers instead of the words. And in terms of speedup, it is not fiction but reality, transforming a program thout would take days into a program that takes hours.

So, please be cautious in what you say and investigate thouroughly. ...a last word though: yeah, for the classic avergae application, it's useless.

Great article. I agree, I think that the general p...

2009-08-28T17:31:21.139-04:00
Great article.
I agree, I think that the general philosophy should be to optimize later, and only if needed.
Looking into a heap dump of you app, during load, you can see right away what are the good candidates for intern.

Sorry but I think the "5 times" observation is inc...

2009-01-08T08:20:00.000-05:00
Sorry but I think the "5 times" observation is incorrect as a general statement.

Can you post the actual code? I would love to see what is actually being measured in your micro-benchmark in particular the strings used and were the deviation happens if some do not match.

I have a cost table beside me for each op (field read, field write, method call,...) and the number you have quoted seems pretty low unless failures in matching happening very early or you are measuring something else.

William

In case you haven't read it: http://kohlerm.blogsp...

2009-01-07T07:02:00.000-05:00
In case you haven't read it: http://kohlerm.blogspot.com/2009/01/is-javalangstringintern-really-evil.html

FYI, that's not my post :)