Hannes, This sounds very interesting. Reading through the page, I found the mention of something I have already experimented with myself:
"...fast paths for overloaded methods called with non-ambiguous arguments. java.lang.StringBuffer.append(java.lang.String) might be an interesting test case." For Scriptographer I modified Rhino to allow more flexibility with object coercion and wrapping, making it possible the write the whole scripting API as pure Java classes, and therefore using it both as an API for Java and JavaScript. Custom wrapper classes and a row of conventions about object coercion then allow me to control the way Rhino makes these native java objects and methods behave in JavaScript. But as a result of these changes, more work had to be done by the interpreter each time when looking up the right method to be called, especially when there were multiple possibilities, as each of them had to be weighted and compared on each call. I especially felt the downside of this with all the variants of java.lang.StringBuffer.append(...), where there are about 11 of them. So I did tests with caching the results of NativeJavaObject.getConversionWeight(Object from, Class<?> to) and saw huge performance improvements. The improvements will be less noticeable with an standard branch Rhino that does not contain my other modifications, but it might still make sense to do so. I am happy to share code if you are interested. Also, if anybody is interested in the other modifications described above, I shall somehow document them and maybe even propose them as a patch. Jürg On 30 Apr 2010, at 01:11, Hannes Wallnoefer wrote: > I've started some some experimental branches on a github Rhino mirror, > mostly related to performance improvement: http://wiki.github.com/hns/rhino-8/ > > Although it's too early to draw any conclusions, some of the results > look promising. Interestingly, it seems like we might want to dump the > IdSwitchable implementation of core objects and just go with plain > Rhino host objects for things like Array and String. > > Git and especially github to be perfect tools for this kind of > experimental coding, as branching and merging is totally painless. If > you're interested please join me there. I'm happy about any help, be > it benchmarks, ideas, or code (the jdk-regexp implementation would be > very nice to have, for example.) > > Hannes > _______________________________________________ > dev-tech-js-engine-rhino mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
