performance problem with e4x

[Massimiliano Mirra]

I came across this while writing a templating engine for Helma.

"js.jar" is built from a fresh cvs.mozilla.org checkout,
"js-noxmlbeams.jar" is the same without
org/mozilla/javascript/xml/impl/xmlbeans/ (thus using
.../javascript/xmlimpl/), "js" is spidermonkey 1.8, java is j2se6,
time is in msecs:

bard@yokai:/tmp/w/seethrough_helma$ java -Djava.compiler=NONE -jar
js.jar -opt 9 e4x_bm.js
times per run: 10000
run #0 total time: 42596
run #1 total time: 48355
run #2 total time: 51056
run #3 total time: 52297
bard@yokai:/tmp/w/seethrough_helma$ java -Djava.compiler=NONE -jar js-
noxmlbeans.jar -opt 9 e4x_bm.js
times per run: 10000
run #0 total time: 38487
run #1 total time: 45523
run #2 total time: 43726
run #3 total time: 46889
bard@yokai:/tmp/w/seethrough_helma$ js e4x_bm.js
times per run: 10000
run #0 total time: 18
run #1 total time: 6
run #2 total time: 19
run #3 total time: 6
bard@yokai:/tmp/w/seethrough_helma$ cat e4x_bm.js
function bm(fn, times) {
times=times||100;
var start=Date.now();
for(var i=0;i<times;i++)
fn();
return (Date.now() - start);
}

var runs = 4;
var times = 10000;

print('times per run: ' + times);

for(var i=0;i<runs; i++) {
var total = bm(function(){ <test/> }, times);
print('run #' + i + ' total time: ' + total);
}

[David P. Caldwell]

Submitted to bugzilla as bug 411895 (https://bugzilla.mozilla.org/
show_bug.cgi?id=411895). I think it's worth looking into --
approaching SM performance may not be possible given the Rhino
infrastructure, but a 2000-4000x differential is notable. :)

What platform are we talking about on which you're running
SpiderMonkey and the JVM?

-- David P. Caldwell
http://www.inonit.com/

[Massimiliano Mirra]

On Jan 11, 2:23 pm, "David P. Caldwell" <ino...@inonit.com> wrote:
> Submitted to bugzilla as bug 411895 (https://bugzilla.mozilla.org/
> show_bug.cgi?id=411895). I think it's worth looking into --
> approaching SM performance may not be possible given the Rhino
> infrastructure, but a 2000-4000x differential is notable. :)

:-)

> What platform are we talking about on which you're running
> SpiderMonkey and the JVM?

The results I posted were from Linux x86 2.6.22 (1.1GHz Intel
Centrino); running on a Linux 2.6.18 x86_64 VPS (dual-core 2GHz AMD
Opteron) gave a similar Rhino/Spidermonkey ratio.

Massimiliano

[Norris Boyd]

On Jan 11, 6:50 am, Massimiliano Mirra <hyperstr...@gmail.com> wrote:

Performing some unscientific instruction sampling (i.e., pausing Rhino
while running your test in the debugger and looking at the stack), it
looks like we're spending most of our time in
com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse().
So I don't have much idea how to improve this short of switching to
yet another XML parser.

I did notice that we were creating a DocumentBuilder from scratch
every time, so I created a simple DocumentBuilder pool. This saved
about 23% on your test case, which is a nice speedup but still leaves
us a couple of orders of magnitude slower than SpiderMonkey for this
case.

--N