Experimental Rhino code on github
Hannes Wallnoefer
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
Jürg Lehni
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
> _______________________________________________
> dev-tech-js-engine-rhino mailing list
> dev-tech-js-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
Hannes Wallnoefer
> I've started some some experimental branches on a github Rhino mirror,
> mostly related to performance improvement:http://wiki.github.com/hns/rhino-8/
I renamed the github repository to rhino-opt, so the overview wiki
page is now at
http://wiki.github.com/hns/rhino-opt/
I also started a new "companion-scopes" branch to speed up closures
which is looking very good on microbenchmarks:
Unfortunately it currently won't run v8-benchmark, but I'm working on
it.
Hannes
Hannes Wallnoefer
>
> I renamed the github repository to rhino-opt, so the overview wiki
> page is now at
>
> http://wiki.github.com/hns/rhino-opt/
>
> I also started a new "companion-scopes" branch to speed up closures
> which is looking very good on microbenchmarks:
>
> http://gist.github.com/390702
>
> Unfortunately it currently won't run v8-benchmark, but I'm working on
> it.
It does now. Performance increase is somewhere around 20 percent,
which seems ok considering that v8-benchmark is not exactly closure-
heavy. I think I'll look at globals and standard object prototypes
next.
Jürg Lehni
Do you have any news about these optimisations? I am curious to hear how the work progresses.
I just came across this post here about similar efforts for JRuby and thought maybe some of the points risen could be of interest for your work:
http://blog.headius.com/2010/05/kicking-jruby-performance-up-notch.html
Juerg
Hannes Wallnoefer
> Hannes,
>
> Do you have any news about these optimisations? I am curious to hear how the work progresses.
I haven't done a lot since my last post. From the microbenchmarks I've
done (see wiki page) it looks like replacing hashed property lookup
with direct java field or method access has the biggest potential, so
this is the route I'll probably follow. Besides using java fields for
the function activation object (which works well except for "eval"), a
similar (slightly less aggressive) approach could be used in other
areas:
- The global object
- Standard methods in core objects
- Object literals
- Objects initialized in a constructor function
For all these cases, the idea is to have "reserved slots" for well-
known properties that are accessible both via normal hash lookup and
directly as a java field. Java bytecode generated for the script can
then simply check if an object is an instance of that specific class
and use the fast property access method if so, else fall back to the
generic property access.
I've done some tests in that direction and they looked promising. I
hope to resume working in that direction soon.
> I just came across this post here about similar efforts for JRuby and thought maybe some of the points risen could be of interest for your work:
>
> http://blog.headius.com/2010/05/kicking-jruby-performance-up-notch.html
I'm sure I've read this at one time, but can't quite remember what it
specifically was about :)
Hannes
> Juerg
>
> On 5 May 2010, at 23:13, Hannes Wallnoefer wrote:
>
> > On May 5, 2:20 pm, Hannes Wallnoefer <hann...@gmail.com> wrote:
>
> >> I renamed the github repository to rhino-opt, so the overview wiki
> >> page is now at
>
> >>http://wiki.github.com/hns/rhino-opt/
>
> >> I also started a new "companion-scopes" branch to speed up closures
> >> which is looking very good on microbenchmarks:
>
> >>http://gist.github.com/390702
>
> >> Unfortunately it currently won't run v8-benchmark, but I'm working on
> >> it.
>
> > It does now. Performance increase is somewhere around 20 percent,
> > which seems ok considering that v8-benchmark is not exactly closure-
> > heavy. I think I'll look at globals and standard object prototypes
> > next.
>
> > _______________________________________________
> > dev-tech-js-engine-rhino mailing list
> > dev-tech-js-engine-rh...@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino