Subj : Re: Replacing SM with Rhino
To   : Matthew Mondor
From : Igor Bukanov
Date : Thu Jan 13 2005 12:59 pm

Matthew Mondor wrote:
>>Has anyone tried or done this before in their embedding/application.
>>APIs are different, of course, but we'd achieve better Java
>>integration and apparently speed. I read somewhere Rhino can be faster
>>10:1 in some benchmark tests, using JIT compilation (not sure here if
>>10:1 refers to Rhino X SM or RhinoJIT X RhinoNoJIT). What would the
>>major issues involved be?
> 
> 
> I'm no definitive authority about this, but I'm rather confident that
> this was comparing Rhino with a JIT and without one... I would be fairly
> surprised if Java performance reached that of compiled C programs
> (except perhaps in cases of very bad programming).

Note that comparing Rhino performance vs SpiderMonkey performance is not 
the same as comparing a general C program with a general Java program. 
Here you compare the performance of JavaScript code compiled to a custom 
bytecode and interpreted using C engine versus performance of JavaScript 
compiled to JVM classes and run through modern JVM.

In general for various benchmarks SpiderMonkey runs faster then Rhino 
under JDK 1.4 by a factor around 1.2 - 1.5 or so although there are 
cases where Rhino beats SpiderMonkey by some margin.

Rhino can also generates a custom bytecode and directly interprets it. 
This is useful to avoid problems that arise when using ClassLoader in 
Java (like memory leaks etc.) and speedup loading of small scripts. In 
this case Rhino lags behind SpiderMonkey by factor up to 5-10. Java 
simply is not suitable for writing high performance interpreters due to 
lack of necessary language constructs.

But all this is relevant only if you use JavaScript to code a lot of 
calculations or complex search algorithms. If JavaScript is used to glue 
native objects then you would not see those performance differences at all.

 > ...
> If Rhino with a JIT exceeds SpiderMonkey performance, I sure would like
> to also know why, as well as the particular code used to test the
> benchmarks

See, for example, https://bugzilla.mozilla.org/show_bug.cgi?id=121414#c57

Regards, Igor

.