On Sep 24, 9:11 pm, "ohad.serfaty" <ohad.serf...
> Hi All
> I have been playing a lot with rhino lately , I have some questions
> regarding script optimization
> 1. are there any stats as to how the optimizer reduces the runtime of
I've modified them to run with Rhino interpreted as well, although I
haven't had the time to get accurate results and in a format to
report. For these kind of compute-intensive tasks, compiling to Java
bytecodes is a significant win. Not sure how typical a workload this
would be, however. I'd expect most Rhino applications to spend most
time in library routines or I/O.
> 2. is it faster to compile a script that will be executed a lot of
> times , and then exec the Script object ?
Yes, you then amortize the compilation costs across multiple script
> is there any difference when
> i use the -1 optimization ?
Yes, -1 means use Rhino's builtin interpreter. 0 and above mean
compile to Java classes.
> 3. stopping the script in higher optimized code is impossible under
> the current rhino conditions. I can use the Thread.stop() method but
> am reluctant to do so as it is unsafe. Is it possible to have a stop()
> or interrupt() function to stop execution of a malicious script thats
> running in highly optimized context ?
You're right that this is a feature request and a good one. The right
way to do this is to implement Context.observeInstructionCount for
compiled mode. There would need to be some way to indicate to the
compiler that you'd like to observe the count, and then compile in
callbacks from the generated Java classes at key points (backwards
jumps, function returns) that increment a counter by some value that
approximates the count of executed Java instructions. The runtime
could then monitor these like is already done for interpreted scripts.
I don't know when I'll get to this (patches accepted!), so in the
meantime I'd recommend using interpreted mode if this feature is
important to your application.