--- jian chen <[EMAIL PROTECTED]> wrote: > 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 ==.
I would bet big bucks for it saving significant amount of time, even with later JVMs. This based on XML parser work, where canonical tokenization (using String.intern() for names) saves lots of time both via reduced GC activity, and due to ultra-fast lookups (esp. when using HashMap etc), latter of which is due to identity comparison being fast. But, if anyone is really concerned about 'impurity' of this optimization, the thing to do really is to do extensive benchmarking and see what happens. Theoretically it is also possible that the overhead of String.intern() may count against using this approach (it's a native method call, always), so there is a chance that for some use cases, String.equals() might be better choice. But I'd be against making this change without benchmarking it well first to avoid potential significant performance degradation. -+ Tatu +- > > Jian > > On 5/1/06, DM Smith <[EMAIL PROTECTED]> wrote: > > > > karl wettin wrote: > > > The code is filled with string equality code > using == rather than > > > equals(). I honestly don't think it saves a > single clock tick as the > > > JIT takes care of it when the first line of code > in the equals method > > > is if (this == that) return true; > > If the strings are intern() then it should be a > touch faster. > > If the strings are not interned then I think it > may be a premature > > optimization. > > > > IMHO, using intern to optimize space is a > reasonable optimization, but > > using == to compare such strings is error prone as > it is possible that > > the comparison is looking at strings that have not > been interned. > > > > 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. > > > > > > Please correct me if I'm wrong. > > > > > > I can commit to do the changes to the core code > if it is considered > > > interesting. > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
