Subj : Re: Spidermonkey performance To : Kumar Iyengar From : Brendan Eich Date : Mon Apr 12 2004 04:53 pm Kumar Iyengar wrote: > I am new to Spidermonkey and was trying to evaluate it with the intention of > using it within our products and performance is one of our biggest concerns. > I did some prototyping and have a few questions: > *) I tried creating one Runtime for all the threads in our product and the > resulting performance was very slow. I have switched to one Runtime per > thread model and found that the performance does improve. Is one Runtime per > thread(or threadpool) the recommended model in a multi-threaded environment? One runtime per thread is not the best model. Why was performance "very slow", and compared to what? Please quantify your claims. > *) If the above is true then does Spidermonkey have to be built with the > JS_THREADSAFE flag? In other words, if i am using the library with one > Runtime per thread model, then can i use js32.dll without compiling it with > the JS_THREADSAFE flag? Yes, you need JS_THREADSAFE. However, since unshared objects (objects used by one thread at a time, or ever) use lock-free synchronization optimizations, I don't believe you can assume that locking at the object level, which is the dominant effect of turning on JS_THREADSAFE, is to blame for anything. Besides giving your elapsed time measurement comparisons, it would help if you profiled your embedding to see where it actually spends its time. Either a pc-sampling profiler such as jprof or gprof, or an instrumenting one such as IBM/Rational Quantify is good for a first cut. > *) Does keeping the compiled version of the script help performance? My > initial tests seemed to indicate that it does not. If you're recompiling the same script every time you execute it, you are indeed wasting effort that precompiling can save. Again, without any numbers, and some kind of profile (even "poor man's pc sampling" where you ctrl-C the program often under gdb and see what stacks you get), it's hard to give a useful comment. If your scripts are combinatorially or numerically complex, they may take so long that they dwarf the compiler costs. > *) Does anyone have any other tips on how to improve the performance. Measure twice, cut once. You are far from "cutting". /be .