headers
alice nodelman | 5 Sep 2007 20:02

state of the new perf farm.

I want to get the minis that are coming online into some sort of 
cohesive plan - since currently I feel like that they are a little all 
over the place.  We have a few issues to address: multi-platform 
multi-branch support, new pageloader vs. old and the use of the 
throttling tool on windows

I don't want anything pushed to the production graph server or to the 
main tinderbox waterfalls without coming up with a plan of how to get a 
set of machine configurations that keeps everyone happy (and are 
producing results that are useful).  I feel like we are moving at a rate 
where we are trying to push to production machines that we haven't 
really settled configuration issues on.

As I see it we need:

1 winxp throttled with new pageloader, branch
1 winxp throttled with new pageloader, trunk
1 winxp non-throttled with new pageloader, branch
1 winxp non-throttled with new pageloader, trunk
1 winxp non-throttled with old pageloader, branch
1 winxp non-throttled with old pageloader, trunk

2 mac with new pageloader, branch
2 mac with new pageloader, trunk

2 linux with new pageloader, branch
2 linux with new pageloader, trunk

As you can see, I'm trying to get most everything shifted over to the 
new pageloader.  I figured that we can keep a couple of the old
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mike Schroepfer | 6 Sep 2007 21:18

Some benchmarks

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
Permalink | Reply | 7 comments |
headers
Robert Kaiser | 7 Sep 2007 18:12
Picon

Re: Some benchmarks

Mike Schroepfer wrote:
> 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...

 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
Permalink | Reply | 3 comments |
headers
Mike Schroepfer | 7 Sep 2007 19:51

Re: Some benchmarks

Robert Kaiser wrote:
> Mike Schroepfer wrote:
>> 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...
> 
>  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
> 

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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert Kaiser | 8 Sep 2007 02:23
Picon

Re: Some benchmarks

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
Permalink | Reply | 0 comments |
headers
Nickolay Ponomarev | 8 Sep 2007 04:37
Picon

Re: Some benchmarks

On 9/7/07, Mike Schroepfer <schrep <at> 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
Permalink | Reply | 0 comments |
headers
Mike Schroepfer | 11 Sep 2007 00:40

Re: Some benchmarks

> 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
Permalink | Reply | 0 comments |
headers
Mike Schroepfer | 11 Sep 2007 00:48

Yet another tweak Firefox perf recommendation

Hey Folks,

http://www.pctipsbox.com/simple-firefox-speed-tweak/

Recommends setting network.prefetch-next to false.

Is this a good idea?

http://www.lifehack.org/articles/lifehack/up-to-date-tips-increasing-firefox-performance.html

Recommends http.pipelining (yikes!), nglayout.initialpaint.delay=0, and 
adding /Prefetch:1 to end of the launching script

Anyone up for taking a pass through the default configs to see if there 
are any settings that should be tweaked?

Best,

Schrep
Permalink | Reply | 6 comments |
headers
Justin Dolske | 11 Sep 2007 01:47
Gravatar

Re: Yet another tweak Firefox perf recommendation

Mike Schroepfer wrote:

> http://www.pctipsbox.com/simple-firefox-speed-tweak/
> 
> Recommends setting network.prefetch-next to false.
> 
> Is this a good idea?

I believe prefetching is only done when a page explicitly requests it 
(and that its use is fairly uncommon), so it seems unlikely that it 
should have any effect most of the time.

>
http://www.lifehack.org/articles/lifehack/up-to-date-tips-increasing-firefox-performance.html 
> 
> 
> Recommends http.pipelining (yikes!)

Ugh. Has there been any discussion of disabling this pref? IIRC, it was 
recently decided that there were still enough problems with it (and 
negligible perf gains?) such that it should remain off for FF3... With 
these kinds of "tweak guides" being so widespread and blindly applied, I 
think there's an argument to be made that having this pref does us more 
harm than good.

> adding /Prefetch:1 to end of the launching script

Hmm, never heard of this.

Ah, MSDN suggests this is totally bogus:
(Continue reading)

Permalink | Reply | 2 comments |
headers
Phil Ringnalda | 11 Sep 2007 06:09
Picon
Gravatar

Re: Yet another tweak Firefox perf recommendation

Justin Dolske wrote:
> Mike Schroepfer wrote:

>> adding /Prefetch:1 to end of the launching script
> 
> Hmm, never heard of this.
> 
> Ah, MSDN suggests this is totally bogus:
> 
> http://blogs.msdn.com/ryanmy/archive/2005/05/25/421882.aspx

It's better than bogus: it's case-sensitive. Using /prefetch:1 would 
make your first startup after adding it a bit slower, and then make 
subsequent runs a tiny bit slower (Firefox's commandline parsing and 
dropping the "unrecognized commandline flag: prefetch" in the error 
console isn't quite free), but using /Prefetch:1, as you can see by 
watching your Windows/Prefetch directory, does nothing but pass an 
unrecognized commandline flag to Firefox.

Phil Ringnalda
Permalink | Reply | 0 comments |

Gmane