Yeah, I believe last slot caching is more than likely not worth having. Increases complexity of the code, for not much if any gain.
Attila. On Sep 29, 2008, at 6:18 PM, Hannes Wallnoefer wrote: > 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
