I am using Spider Monkey to add scripting capability to my app. I have
had it running for quite a while with no problems. I have a single
JSRuntime and a single JSContext. Since I started, I have given my
JSContext a 100K byte stack. Today I changed that to 1 Meg and the
script that I was testing with slowed down by a factor of 25 to 30
(from about one-quarter of a second to over 6 seconds). When I
increased the stack size to 10 Meg, the script slowed down by another
factor of about 6.

All of the time can be accounted for in the execution of the
JavaScript code. I call the JS code from C++, and it calls into my C+
+,
but I have satisfied myself that the delays are not in the C++
code. The script code I'm running is marshaling and unmarshaling
objects to JSON. It appears that doing an eval on the JSON encoded
data is taking 3-4 seconds when I have a 1 Meg stack. That accounts
for a lot of the extra time right there.

Has anyone else seen anything like this? I searched the list archives
and didn't see anything that looked similar.

Here is a related question: Does anyone have any stack size
guidelines? I have read js_InternalInvoke and it sets up the stack
frame size as ((argc + 2) * 4) bytes, and I also see that js_Invoke
allocates space for local variables and missing arguments on the
stack. I might be fine with a 100K stack, but my customers will be
writing the scripts, so I don't really have any control over what they
do.

Any help would be greatly appreciated.

- Rush

I made a mistake when I reported this. I got an offer of help as a
reply off list. While creating the example, I realized that eval() was
not what was taking longer. It was the JSON serialization code, which
was still in a logging function call. I still don't know why stack
size changes the timing (it is a factor of about 30 slower for a 100
times larger stack), but eval() is not a problem.

- Rush

On Mar 5, 1:47 pm, Rush <r...@manbert.com> wrote:

Hi Rush,

Short answer:  Use 8192 and don't worry. :)

Long answer: The parameter to JS_NewContext() is not the stack size.
The documentation in the wiki is wrong.  The parameter is actually the
chunk size of the stack pool--an obscure memory management tuning
knob.

Which knob *should* you be tweaking, then?  Probably none.
SpiderMonkey's stack behavior is not what you might expect.  When a
JavaScript function calls another JavaScript function, it doesn't use
any C stack at all: JavaScript stack frames are allocated from the
stack pool (heap memory).

The limit for recursion depth among JavaScript functions is 1000 calls
(MAX_INTERP_LEVEL, defined in jsinterp.c).  This is way high.  Every
time I've ever hit this limit, it was a bug in my JavaScript code.

By the way-- the slowness you're seeing only happens in debug builds.
In a debug build, each time arena memory is freed, SpiderMonkey does a
memset() across the entire unused portion of the arena chunk.  (See
JS_CLEAR_UNUSED, defined in jsarena.h).  This makes memory look tidy
in a debugger, but when the chunk size is very large, it's slow.  In
release builds ("make BUILD_OPT=1 -f Makefile.ref"), the memset()
doesn't happen.

Cheers,
Jason Orendorff

Jason,
Can you update the wiki and fix it?

Here is the link:  http://developer.mozilla.org/en/docs/JS_NewContext

That one got me too.
8K versus 8Megs makes a BIG difference!

news:1173335573.424409.256400@p10g2000cwp.googlegroups.com...