Some benchmarks

[Mike Schroepfer]

Hey Folks,

Some interesting performance tests:

http://nontroppo.org/timer/kestrel_tests/

The pageload numbers looks strange as he's showing a much much bigger
gap between FF2/FF3 then we are currently measuring on Talos. I'm also
a bit surprised on the JS numbers based on JResig's benchmarks...

Schrep

[Robert Kaiser]

From a quick look, don't all those tests heavily stress DOM methods?
From what I heard, we know that we really suck in DOM manipulation
performance - something that e.g. also apps like ChatZilla feel heavily.

Robert Kaiser

[Mike Schroepfer]

Some do - some don't. The raytracer spends most of it's time creating
new DIV's, setting style on them and appending them. The Mesh transform
(source below) is pure JS as far as I can tell. Very math heavy.

var loops = 60
var nx = 120
var nz = 120

function morph(a,f) {
var PI2nx = Math.PI * 8/nx
var sin = Math.sin
var f30 = -(50 * sin(f*Math.PI*2))

for (var i = 0; i < nz; ++i) {
for (var j = 0; j < nx; ++j) {
a[3*(i*nx+j)+1] = sin((j-1) * PI2nx ) * -f30
}
}
}

var a = Array()
for (var i=0; i < nx*nz*3; ++i) a[i] = 0

var startTime=new Date() ;
for (var i = 0; i < loops; ++i) {
morph(a, i/loops)
}
var endTime=new Date() ;

[Robert Kaiser]

Mike Schroepfer wrote:

> Robert Kaiser wrote:
>> From a quick look, don't all those tests heavily stress DOM methods?
>

> Some do - some don't. The raytracer spends most of it's time creating
> new DIV's, setting style on them and appending them. The Mesh transform
> (source below) is pure JS as far as I can tell. Very math heavy.

Hmm, I thought we would perform better on those on trunk. Seems like
either we aren't or the test is flawed. In the former case, which might
be probable, I guess that still Tamarin will help us in the future, but
not yet for FF3.
DOM perf still seems to be something where we lag behind, and even the
magic Tamarin will probably not help much there :(

Robert Kaiser

[Nickolay Ponomarev]

On 9/7/07, Mike Schroepfer <sch...@mozilla.com> wrote:
> The Mesh transform
> (source below) is pure JS as far as I can tell. Very math heavy.
>

> var sin = Math.sin
> var f30 = -(50 * sin(f*Math.PI*2))
>

FWIW, on my system Fx3 is 3 times faster if Math.sin is used directly.
Otherwise we spend much time in security checks it seems
(ComputeGlobalThis/js_CheckAccess/nsScriptSecurityManager).

Nickolay

[Mike Schroepfer]

> FWIW, on my system Fx3 is 3 times faster if Math.sin is used directly.
> Otherwise we spend much time in security checks it seems
> (ComputeGlobalThis/js_CheckAccess/nsScriptSecurityManager).

Interesting - thanks! I get about a 60% speedup for Trunk on Vista
(MacBook Pro) which puts us within 20% of Webkit on this benchmark
(rather than 2x off).

Is it possible to optimize out the security checks in the first case?
Anything interesting show up in the profiles if Math.sin is used directly?

Best,

Schrep

[Boris Zbarsky]

Mike Schroepfer wrote:
> Some interesting performance tests:

In order:

Raytracer (basic): Lots of getting the last frame in the abs pos frame linked
list. About 20-30% of total. See bug 233463. On the other hand, only about
50% of the total time is spent making the actual Gecko function calls in
question (appendChild, setting CSS properties, etc). That includes the 20-30%
above as part of the 50%. Another 14% is spent painting. The rest (30+%) looks
like possible moz2 fodder: JS and XPConnect stuff.

Mesh transform: About 60% of the time is under js_CheckAccess, called from
ComputeGlobalThis. Lots of XPConnect and getting of object principals. We have
some bugs on making this last better, but why are we doing so much
js_CheckAccess here? It sounds like this was discussed in this morning's
performance meeting; it would be nice to have someone who was present post an
update.

3D cube: see bug 229391.

Celtic Kane: See bug 386771, bug 386770, bug 386769.

Core DOM: About 35% of the time here is actually spent in DOM code. Almost half
of that is in memmove while inserting lots of stuff into a children array near
the beginning. 20% or so is spent under XPCWrappedNative::GetNewOrUsed (finding
tearoffs, initializing them, precreate, etc, etc). Definite moz2 fodder there.
5% is spent in security checks. The rest looks like moz2 fodder.

DOM animation: See bug 297959.

Page loading: No obvious way to reproduce his methodology, so didn't try.

> The pageload numbers looks strange as he's showing a much much bigger
> gap between FF2/FF3 then we are currently measuring on Talos.

Agreed. I wonder whether there are significant numbers of background images on
these pages that now delay onload but didn't use to. Or whether something else
is up...

> I'm also a bit surprised on the JS numbers based on JResig's benchmarks...

You mean the mesh test? Or something else?

-Boris

[Brendan Eich]

Boris Zbarsky wrote:
> Mesh transform: About 60% of the time is under js_CheckAccess, called
> from ComputeGlobalThis. Lots of XPConnect and getting of object
> principals. We have some bugs on making this last better, but why are
> we doing so much js_CheckAccess here? It sounds like this was discussed
> in this morning's performance meeting; it would be nice to have someone
> who was present post an update.

These checks were added at this low level to compensate for design flaws
elsewhere: xpconnect and caps. We should remove these checks and use XOW
proxies elsewhere to re-optimize.

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=395993.

/be

[Schrep]

> > I'm also a bit surprised on the JS numbers based on JResig's benchmarks...
>
> You mean the mesh test? Or something else?

Yep - that one.