A couple of responses to various comments in this thread...
: > Unless it object identity is what is being tested or intern is an
: > invariant, I think it is dangerous. It is easy to forget to intern or to
: > propagate the pattern via cut and paste to an inappropriate context.
interning the Strings before doing the object equality test is an
invariant of all the lucene internals I've ever looked at ... if you think
there's a particular spot where this is not garunteed, please point it
out.
: I am wondering if interning Strings will be really that critical for
: performance. The biggest bottle neck is still disk. So, maybe we can use
: String.equals(...) instead of ==.
1) disk is not going to be a bottle neck if your entire index lives in
RAM, particularly if you are using a RAMDirectory (and not even relying on
the filesystem cache)
2) I think you are missing the point of an earlier comment (either that or
i am). In the case where this *does* equal that, there may not be much
advantage to...
void doSomething(String a, String b);
String aa = a.intern();
String bb = b.intern();
if (aa == bb) {
...
}
}
...versus...
void doSomething(String a, String b);
if (a.equals(b)) {
...
}
}
...since the very first thing String.equals does is an object equality
test -- but in the case where the two strings are *NOT* equal, interning
and using == saves the cost of testing succesive characters (or bytes,
whichever String.equals might use, i haven't looked lately). This should
make a significant differnce when the common case is that most comparisons
will fail (ie: scanning a TermEnum looking for a particular input string)
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
