Thanks for the link, interesting stuff. After looking through info on Rhino, I was left with the question... why build the JS core engine in Java and not a non-interpreted language? Then I looked at info in Spidermonkey (a C re-write for Firefox 3) and saw they realized the same thing. Hopefully as it matures (Firefox 4+) we'll see the speeds really drop.
So I guess the answer to my question is that currently the bottleneck with Javascript is how quickly the engine can interpret the code, which right now appears to be how the engine itself is coded (like all interpreted languages). Then you have the browser that has to render the layout, and that's a whole other issue. Now I see why Javascript is still in it's infancy and has a bit of a speed problem. I also wonder where we'd be if Microsoft hadn't essentially halted development on IE (and it's js engine) for 3 or so years. In looking at speed tests out there, it looks like Opera has far & away the fastest JS engine. On 10/1/07, Robert Koberg <[EMAIL PROTECTED]> wrote: > > > On Mon, 2007-10-01 at 16:46 -0700, John Beppu wrote: > > http://ejohn.org/blog/javascript-engine-speeds/ > > > > Very interesting! I have been using rhino for a week or so. When I > started looking at the results, it was very disappointing. Then I got to > the real world examples. Why does rhino shine there and smokes a turd in > the other tests? Are compiling to classes for the real world tests and > loading from string for the others? > > best, > -Rob > >
