On Jun 19, 9:56 am, Norris Boyd <[EMAIL PROTECTED]> wrote:
> On Jun 19, 9:28 am, "Ruland Kevin-BHP637" <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > I ran this through jprofiler and found some blockage.
>
> > Here's a short list:
>
> > During Startup the following show up:
> > ScriptRuntime.initStandardObjects( Context, ScriptablObject, boolean )
> > NativeGlobal.init(Context, Scriptable, boolean)
> > NativeArray.<init>(long)
> > NativeDate.<init>() -- in TimeZone.getDefault() actually.
> > NativeIterator.init(ScriptableObject, boolean)
> > ContextFactory.isDom3Present() -- Kit.classOrNull(String) --
> > j.lang.forName(String)
> > ContextFactory.getE4xImplementationFactory()
>
> > Then during execution of the loops:
>
> > Context.compileImpl(Scritpable,Reader,String,String,int,Object,boolean,E
> > valuator,ErrorReporter)
> > CompilerEnvirons.<init>()
> > Parser.parse(String,String,int)
> > TokenStream.<init>(Parser,Reader,String,int)
> > Parser.createDecompiler(CompilerEnvirons)
> > Parser.parse()
> > Codegen.transform(ScriptOrFnNode)
> > NodeTransformer.transformCompilationUnit(ScriptOrFnNode);
>
> > Codegen.compileToClassFile(CompilerEnvirons,String,ScriptOrFnNode,String
> > ,boolean)
> > Codegen.generateCode(String) ==
> > ClassFileWriter.<init>(String,String,String)
> > ConstantPool.<init>(ClassFileWriter)
>
> > There are many others. One notable is:
> > DefiningClassLoader.loadClass(String,boolean) --
> > j.lang.ClassLoader.loadClass(String) which is, I think, when rhino loads
> > the compiled class for execution.
>
> > I changed the example by naming the scripts uniquely per thread by
> > changing one line of code:
>
> > Script script = cx.compileString("new Date()",
> > Thread.currentThread().getName(),0,null);
>
> > Visual inspection of the blocking shows this is better behaved. Perhaps
> > Rhino should do something smarter when the script name is null?
>
> > I am confused by the contention during startup. I would not have
> > expected there to be so much contention, I suspect its all in
> > sealObject.
>
> > Kevin
>
> > -----Original Message-----
> > From:
>
> > [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> > lla.org] On Behalf Of [EMAIL PROTECTED]
> > Sent: Thursday, June 19, 2008 3:54 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Mozilla rhino performance issues under multithreads
> > environment
>
> > I took a thread dump. But, unlucky, I cannot see any "wait at ..monitor"
> > message.
>
> > There should have something blocked threads running!!!
>
> > Anybody could help me?
>
> > _______________________________________________
> > dev-tech-js-engine-rhino mailing list
> > [EMAIL PROTECTED]://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
>
> If your performance model is really to compile scripts extremely
I can testify that interpreted mode results in considerably better
performance see. setOptimizationLevel on Context.
If you are reusing the same snippet presumably you can cache the
precompiled objects and then parameterize them thru the scope object?
Similar in concept to how prepared statements would be applied? Is
this possible? If you have a block of javascript that you want to
parameterize because you're evaluating the same block for many records
and it's the data of those records that's used as parameters in the
script. then you want to be able to take a one time cost to precompile
the script but be able to vary it's parameters. Currently we do this
thru string substitution as it gets the job done but I assume that
using "put" on scope is a better way to do this.
> often, you should use interpreted mode rather than compiled mode. As
> noted above, compiled mode implies Java classfile loading and is much
> more heavyweight than interpreted mode. I wouldn't be surprised if
> Java's loading of classes contains some locks that this test hits.
>
> Alternatively, if you can compile scripts once and run multiple times
> then compiling will likely pay off.
>
> I don't understand how naming the scripts uniquely per thread would
> make any difference to performance. This name is just used for error
> messages and for debug information, as far as I can recall.
>
> --N
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
