Currently on the following VMs (QA-Horus) I am experiencing what I believe to be slower than normal test runs in the tests that make use type() (e.g, the AwesomeBar tests [firefox/testAwesomeBar]) * Windows XP IE8 * Windows Vista SP2 * Windows 7 Pro * Windows 7 x64 * Did not test on Windows 2000 In comparison, one can witness the speed difference/variance in: * Ubuntu 10.4 & Ubuntu 10.4 x64 * Mac OSX 10 I'm positive this used to be quicker, and might be worthwhile for investigation in order to ultimately get quicker test runs. Henrik, is this the same behaviour you saw two weeks ago in the e-mail thread?

This sounds like the same behavior. Henrik noted at the time that it seemed to be Firefox 4 specific. Are you seeing the same speed issues if you run the awesomebar tests on Firefox 3.6 nightlies?

No, this seems 4.0 specific.

I'm curious as to whether it happens if you run on a windows machine that isn't a VM. This all sounds like a Firefox 4 bug.

(In reply to comment #3) > I'm curious as to whether it happens if you run on a windows machine that isn't > a VM. This all sounds like a Firefox 4 bug. Marcia was the first person who reported an issue like this to me, during the 4.0b8 cycle. Her analysis seemed to point toward the slowdown only occurring while Sync was active (either doing a background sync, foreground sync up, or foreground sync down). Henrik noticed this during the Mozmill testruns during the same release cycle. However, he saw it as an issue with Mozmill in a VM, causing both Henrik and Al to do various things to troubleshoot it from that perspective (rebooting the VM, restoring from snapshot, creating a new VM). I think this is indeed a Firefox bug and should be treated as such. I think we should have enough trust and faith in Mozmill and our infrastructure to point the finger at Firefox whenever really weird stuff like this happens.

Aaron, could you compare the performance by running the awesomebar tests with b7? Would be even better to get a clear regression range, so we could blame a specific changeset.

I've narrowed this down to a Firefox 4 beta 6 (working) beta 7 (not working) regression, but there are 1625 bugs fixed between those releases http://goo.gl/0s329 and the changelog (I used build 2 of b6 and build 1 of b7) which is massive (sept->nov) http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=633e895d5e84&tochange=297086a0fb61 -- to narrow this down more, not sure

What about nightly builds as what we normally do to find regression ranges? Is it not reproducible in nightly builds?

(In reply to comment #7) > What about nightly builds as what we normally do to find regression ranges? Is > it not reproducible in nightly builds? It is reproducible in Minefield nightly builds.

Generally, we'll narrow to a nightly build and then look at what was checked in on that day.

Seeing beta9 coming up very soon, it would be great to get the regression date. Aaron, would you be able to nail it down?

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bd474ff6f86c&tochange=fd13b6ce36bd Sept 4th - Good: bd474ff6f86c Sept 5th - Bad: fd13b6ce36bd

Thanks Aaron. The interesting fact here is, that in this time frame the Direct3D accelerated Layers have been activated by default on Windows. I would really blame this feature to be causing this issue. Aaron, can you please disable Direct3D and check if the issue goes away? Moving to Core:Graphics for further investigation.

Asking for blocking2.0, because it's a major regression on some systems. Also see the newsgroup thread: http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/42b41d705c4f8279#

Definitely a regression from bug 581212. Disabling causes our tests to run in normal speed.

It's not clear to me if anybody experiences this on a non-VM. (VMs are known to be pretty slow wrt hardware acceleration.) http://groups.google.com/group/mozilla.dev.planning/browse_frm/thread/a754afdccebdec54 shows that the original reporter has this mostly fixed using new nightlies.

We should be blocking hardware acceleration on VMs. You can check in about:support to make sure that there are no accelerated windows. If you still see slowness please re-open noting if you are getting accelerated windows. See bug 623338.