Subj : Re: Spidermonkey performance
To   : Kumar Iyengar <iyengar@remedy.com>
From : Brendan Eich <brendan@meer.net>
Date : Mon Apr 12 2004 06:48 pm

Kumar Iyengar wrote:

> I ran the tests using the 'one runtime for all threads' versus 'one runtime
> on a per thread basis' and found that the latter performed about 3 times
> better. In both cases I have:
> BeginRequest
> EvaluateRequest
> EndRequest
> GC


You might put timestamping log calls around the four calls sketched 
above, and another one before the GC call.  You may well find the time 
dominated by GC.

You're abusing the API.  There's no point GC'ing until enough garbage 
has piled up that it's worth it.  Try running GC every N seconds in the 
background, on a dummy context in the same runtime.  Try JS_MaybeGC. 
Don't call JS_GC after every script execution.


> I also have SuspendRequest and ResumeRequest around native code that blocks.
> In anycase, the performance i am measuring was between the 2 models.
> I was hoping that this is an area that has already been investigated and if
> there were any guidelines or such that i should be following.


See above.  Garbage collection via mark and sweep can be time-consuming, 
if the runtime has many live objects.  If it has almost no garbage to 
collect, you are wasting time.  The trick is to get the time spent 
collecting down to a few %.

I hope it's clear now why a runtime per thread makes things faster. 
Each runtime has its own GC heap, so the smaller the heap, the faster a 
mostly-useless GC takes to complete.

Do useful GCs, and you would then want one runtime per process.

/be

.