Tei writes:

> On a web browser, javascript is integrated into the browser. This mean
> a JS script is directly evaluated, while a Java applet need to load
> the virtual machine.

Typically true, but the details are quite implementation dependent.  I 
think it's fair to say that viewed from far enough away, the Browser/Java 
pairing is quite similar architecturally to the Browser/.Net Common 
language runtime pairing.  I haven't measured it myself, but I'm told that 
Microsoft put a lot of effort into lowering the overhead in crossing from 
ordinary (unmanaged) code such as you might find in a native browser, into 
code in the VM.  I seem to recall claims as low as 4 machine instructions 
or so to get in and probably similar to return.  Most of the Java calling 
interfaces had much higher overhead last time I checked.  I don't think 
there's anything inherent in Java that would make it harder to optimize 
than .Net, but perhaps there is.  I suspect that the difference may be in 
whether you carry enough context to allow the C code to do things like 
return Java objects to the garbage collector, which is a design choice 
available in either case. 

Anyway, I think there's an important principle at work here:  when you 
measure something like the JavaScript/Browser pair and show that it can 
run at a certain high speed you've proven that it's possible to go at 
least that fast.  When you measure the Browser/Java pairing and show that 
it's slower, you've only proven that there exists a slow implementation. 
You haven't really demonstrated much about what's possible in principle.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------