Subj : Re: Performance?
To   : netscape.public.mozilla.jseng
From : Rickard <rickard@dreambean.com>
Date : Fri Jun 20 2003 04:32 pm

Igor Bukanov wrote:
>> But, these scripts will run over and over again. Isn't it better to 
>> have them compiled in that case? 
> 
> How do you execute the script now? Do you use Context.compileScript() 
> and call Script.exec() later or call Context.evaluateString directly 
> which just a convenience method to call the above sequence? 

I call compileScript() once and exec() them later on (I have a hashmap 
cache with the script String as key and the compiled script as value).

> Note that Context.compileScript() always compile a script to internal 
> presentation and then that internal presentation is executed. The 
> difference between setOptimizationLevel(level >= 0) and 
> setOptimizationLevel(-1) is that the first one is JVM bytecode which is 
> loaded via a custom classloader and to execute the script Rhino simply 
> calls it. In the second case the internal presentation is a special 
> bytecode that is interpreted during execution.

That's what I figured, but I thought the JVM bytecode version would be 
faster, and it doesn't seem to be, at least not with the scripts I've tried.

>  > Is the access of Java objects different
>  > depending on whether the script is compiled or not? Why would it be
>  > faster in the interpreted mode?
> 
> Context.compileScript() is significantly faster in the interpreted mode 
> because it does not need to load Java classes which can be very slow. 

That is only run once, so I don't care about the performance of that.

> In 
> addition the internal Rhino bytecode for JavaScript is simpler and 
> faster to produce from the script parse tree then to generate JVM bytecode.

But that still doesn't answer my question. Why are bytecode-compiled 
scripts slower than interpreted ones?

And the question of whether there's an overhaul of performance in Rhino 
coming up is also still unanswered.

/Rickard

.