Closed Bug 385243 Opened 17 years ago Closed 5 years ago

Investigate a way to measure tab switching performance on the Mac

Categories

(Testing :: General, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INACTIVE

People

(Reporter: marcia, Unassigned)

References

()

Details

Attachments

(2 files)

Seen while testing Minefield on the Intel Mac. 

STR:

1. Open a few tabs (include gmail, yahoo, cnn.com).
2. Switch between them, fairly rapidly.

The first thing I noticed after all my 2.0.0.x testing is that there is significant difference in tab switching between the two builds. I have checked both builds on the same machine (Intel Mac with 512 MB RAM). In speaking with Josh last Friday, he noted that pav and vlad would be landing some optimizations that would help here. I am interested in investigating the pre and post code landing situation to see if things really improved in this area.
this would be interesting to measure as I've noticed some pretty significant differences in tab switching performance. This could likely be built as an extension pretty quickly.

Opinions, vlad?
Attached file testcase
This is a testcase that switches tabs quickly. It's switching tabs 20 times * the amount the tabs you have open.
When I have gmail.com (logged in), yahoo.com and cnn.com open, I get as results:
Current trunk build: 7047ms
Fairly recent branch build: 6406ms
This is on windowsXP.

The testcase uses privileged code, so you need to download it to your computer to be able to use it.
with 4 tabs open (gmail.com (logged), yahoo.com, and cnn.com + the tabswitcher), I get

* 39799ms (latest trunk nightly)
* 10025ms (latest branch nightly)

Both are on a PowerMac Dual G5 2.0GHz machine with lots of RAM and a bunch of other stuff running (but running similarly during both tests). Latest OS X (10.4.9).

Ick, imo.
ps, that was run with a clean profile in both versions.

pps, nice work martijn! That was fast!
Here are my results from the lab PPC machine - during both runs I used a fresh profile and was logged into Gmail, but not Yahoo. It was interesting to watch how this went down testing on a slower machine since you could really notice the difference between the two. I will also test on a PPC G5 as soon as Zach finishes his Leopard install.

Machine info: Mac OSX 10.4.10, 533 MHz PowerPC G4, 1.25 GB RAM

Firefox 2.0.0.4:
this took: 29826ms
you had 4 tabs open
tab 0: file:///Users/marcia/Desktop/switchtab.htm
tab 1: http://www.cnn.com/
tab 2: http://www.yahoo.com
tab 3: http://mail.google.com/mail/

Minefield run, latest nightly:
this took: 156412ms
you had 4 tabs open
tab 0: file:///Users/marcia/Desktop/switchtab.htm
tab 1: http://www.cnn.com/
tab 2: http://www.yahoo.com/
tab 3: http://mail.google.com/mail/
This is an IRC log between Hixie and bz that discussed changing some prefs. to speed this up. Might be interesting to play with these and see if we can tell a difference like Hixie did.

AFAIK, there was never a bug filed on reevaluating the default values of these prefs.
What would be really nice would be to run some profiling tools over these testcases. Mac OS X comes with a number of them. sample(1), Sampler.app and Shark.app are all good things to run.
Here are results from PPC G5, which show a slight difference from robcee's in Comment 3. Safari was the only other app running on the machine.

Mac OSX 10.4.10
Dual 1.8GHz PowerPC G5
1.25 GB RAM

Firefox 2.0.0.4

this took: 11018ms
you had 4 tabs open
tab 0: http://www.cnn.com/
tab 1: http://www.yahoo.com/
tab 2: http://mail.google.com/mail/?
tab 3: file:///Users/mozilla/Desktop/switchtab.htm

Latest Trunk

this took: 67889ms
you had 4 tabs open
tab 0: http://www.cnn.com/
tab 1: http://www.yahoo.com/
tab 2: http://mail.google.com/mail/?
tab 3: file:///Users/mozilla/Desktop/switchtab.htm
Can we roll this test into Talos? 
I think that this test could be integrated into Talos - maybe we should open another bug for that integration?
Filed bug 385512 for getting this test integrated into Talos.
martijn's testcase no longer works for me in Alpha 7 and in the latest trunk nightlies. I fail with this error in the console: Error: uncaught exception: A script from "https://bugzilla.mozilla.org" was denied UniversalXPConnect privileges. I specifically wanted to try to run this against A7 since I am seeing slow tab switch performance.
martijn's testcase no longer works for me in Alpha 7 and in the latest trunk nightlies. I fail with this error in the console: Error: uncaught exception: A script from "https://bugzilla.mozilla.org" was denied UniversalXPConnect privileges. I specifically wanted to try to run this against A7 since I am seeing slow tab switch performance.
Marcia, I think it might work again if you put this:
user_pref("signed.applets.codebase_principal_support", true);
in your prefs.js file, which is in your profile directory.
thanks martijn, i tried that pref on the mac but the test still does not run :(.
(In reply to comment #14)
> Marcia, I think it might work again if you put this:
> user_pref("signed.applets.codebase_principal_support", true);
> in your prefs.js file, which is in your profile directory.
> 

Martijn: Still won't run correctly for me on the Mac, I added the line in comment 14 as well as three prefs you emailed me:
user_pref("capability.principal.codebase.p0.granted", "UniversalXPConnect");
user_pref("capability.principal.codebase.p0.id", "file://");
user_pref("capability.principal.codebase.p0.subjectName", "");

The script starts, but I keep getting the dialog popping up and it doesn't blaze through all the tabs like it used to.
Marcia, does it work with a new profile?
It does not seem to work with a new profile, either with or without the additions to the prefs.js file noted above. I get this message in the console: Error: uncaught exception: A script from "https://bugzilla.mozilla.org" was denied UniversalXPConnect privileges. I am using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.9a8pre) Gecko/2007092104 Minefield/3.0a8pre.
Looks like you are granting UniversalXPConnect privileges to file:// and running a script through https://.  You might have better luck copying the script locally and then running it through file open. 
Oh, yes, sorry, I didn't know you were trying the script online (I wasn't paying attention to the url), you need to download the script to your computer and use it there to get it working.
Here are my best results:
this took: 11091ms
you had 5 tabs open
tab 0: file:///D:/switchtabs.htm
tab 1: http://www.mozilla.org/
tab 2: http://www.google.com/
tab 3: http://www.ebay.com/
tab 4: https://bugzilla.mozilla.org/show_bug.cgi?id=385243
(In reply to comment #21)
> Here are my best results:
> this took: 11091ms
> you had 5 tabs open
> tab 0: file:///D:/switchtabs.htm
> tab 1: http://www.mozilla.org/
> tab 2: http://www.google.com/
> tab 3: http://www.ebay.com/
> tab 4: https://bugzilla.mozilla.org/show_bug.cgi?id=385243
> 

Thanks!  Can you post machine specs and the results for 2.0.0.8 v.s. a recent trunk nightly?
After installing the nightly, I can't go back to the 2.0 line, as Fx crashes when I launch non-nightly (Maybe because I installed it same folder as Nightly?).

System specs:
Intel Celeron M 440 running at 1.87gHz
502? MB of RAM
Intel 945GM Integrated Graphics

This is my lousy Acer Aspire 3680, which hopefully be replaced by something running at least 2 gHz with a gig of RAM & better graphics.
I am tracking some of my test results on http://wiki.mozilla.org/QA/Firefox3/TestPlan/Tab_Switching.
Marcia - can you re-test 2008 - it is not at all obvious to me why the numbers jumped so high for branch nighties.  Also make sure the machine state is consistent - e.g. nothing substantial running in the background.
No longer blocks: 386081
Everything left in Core:Testing is going to Testing:General. Filter on CleanOutCoreTesting to ignore.
Component: Testing → General
Product: Core → Testing
QA Contact: testing → general
I guess this has been fixed by some Snappy/Telemetry work. Close this bug?
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: