I did some real testing today and what I found is that trying to update slot names in order to match with == rather than String.equals() is a good idea, although the difference is really small with modern JVMs.
The picture is really different depending on whether script code is evaluated by the Interpreter (optimization level -1) or the native bytecode compiler (optimization level >= 0). With the interpreter, each string or name in the code creates a new string instance, so different string instances are used depending on the locality of the property name. I tried using String.intern() during parsing/compilation, but the gained speed seems marginal and the risk of memory clogging seems too large, especially with eval()ed code etc. With scripts compiled to Java bytecode, the picture is really different from the beginning as string constants and literals in java code are always intern()ed. So we always see the same string instance except for strings that are composed at runtime and basically get free == comparison hits on 99% of real world cases here, which is nice. During my tests I also found that some standard properties (namely error constructors and standard java package names) don't use intern()ed property names. The reason is that they make use of a slightly awkward string splitting mechanism during initalization. While this is mostly a cosmetic problem I think the code could be simplified and have filed a bug that contains a patch: https://bugzilla.mozilla.org/show_bug.cgi?id=457705 Other than that, I think the we should keep the code in its current form. Again, sorry for posting before doing some real testing :-) Hannes On Sep 27, 8:17 am, Hannes Wallnoefer <[EMAIL PROTECTED]> wrote: > Oops, please take my posting with a grain of salt. Turns out that the > _big_ performance difference was due to a change in my own code which > I had overlooked. I still think it's possilbe that the name swapping > code in ScriptableObject.accessSlot is not really an improvement, but > it probably doesn't make that big a difference. > > Hannes > > On Sep 27, 12:50 am, Hannes Wallnoefer <[EMAIL PROTECTED]> wrote: > > > I think there may be a serious problem with the code in > > ScriptableObject.accessSlot() that updates the slot name in order to > > avoid future calls to String.equals(). I suspect that updating the > > field repeatedly may have a bigger performance impact than calling > > String.equals() - at least that's what my limited testing suggests. I > > found that for a simple property access from the shell, the name gets > > swapped not once but _twice_, and scripts that ran inexplicably slow > > before now run really fast. Other scripts that have been fast before > > seem unaffected. I guess it really depends on how and how often you > > access properties. > > > Can somebody look into this? > > > hannes _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
