Closed Bug 525323 Opened 10 years ago Closed 10 years ago
Windows CE ux/perf regression between Alpha 2 and Beta 1
On the newest (10/16) OS build, the preinstalled Firefox (Alpha 2) is fast and snappy, but Beta 1 is not. Specifically, it seems fast for brief spurts, and otherwise bogs down and is almost completely frozen for up to a minute at a time. I tested with downloading the A1/B2 .zip builds and running them from the SD card, so it seems to be related to something that changed in our code. STR: 1) Ensure Firefox faststart process is not running. [You may want to just install Firefox from the OS, so that a reboot ensures it's always gone. File->Exit from the browser will also ensure it's gone -- just closing the browser window with [x] does not] 2) Run a Firefox build. 3) Browse a couple of sites, wiggle the mouse pointer around with the trackpad. Good: sites load quickly, mouse pointer generally moves smoothly Bad: browser seems frozed (loading, or typing in URL bar, or opening menus), mouse pointer moves in jerky steps. A few interesting quirks I've noticed: * When things freeze up, moving the pointer with the trackpad exhibits jerky motion, but moving it with a USB mouse is fine. * After a page is loaded and things seem fine, I can generally wiggle the pointer in an empty area of the page, but touching a link or UI button will often trigger the freezing / slow cursor. * On the 10/16 OS build, the difference between A2 and B1 is night-and-day. On earlier builds and the last Oban build, I have a hard time telling them apart -- they're both really slow.
CCing QA, narrowing down the regression window would be a huge help.
Assignee: nobody → dolske
Yes, I just mentioned that I was seeing this to rstrong. Will start the regression hunt.
Any progress on a regression range for this? This bug is critical for us atm, we can't deliver builds unless we track it down.
none to report atm. however, marcia and i will get onto hunting this down as soon as we ship 3.6b1 today. dolske, is there a particular site or sites you can point out that will help us narrow down this rat race? Also, i assume we want to target builds between Alpha 2 (9/20/09) and (10/16) nightlies?
I am working on this intermittently as we try to ship B1. I did install the 20090929 build and I see the same horked state. However, the OS becomes unstable when I try to restart, which makes testing difficult. At times I have still had this version of the OS become unstable - the Namoroka nightlies freeze in the middle of loading. Also, rstrong suggested I try shutting off JIT chrome as well as deleting compreg.dat and compatibility.ini. But I haven't had too much luck getting the browser into a state where I could actually change the JIT state yet.
(In reply to comment #4) > dolske, is there a particular site or sites you > can point out that will help us narrow down this rat race? Just try going to a couple of basic sites like mozilla.com and google.com. It's quickly obvious if it's working or not. [I'd avoid complicated sites pulling in Flash and other crud for the purposes of this bug.]
Narrowed down range: 09-15-04 nightly is ok. 09-19-03 nightly is bad. Alpha 2 build 1 branched on 9/16, so this seems likely to be something that landed soon after branching.
09-16-03 nightly is ok 09-17-03 nightly is bad. Checked each build twice, rebooting in between. Regression range: http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?fromchange=0ee58a54c5d6&tochange=34da890d632d Bug 511167 immediately makes me suspicious (as it did when it landed, now I wish I has tested that specifically), especially after having dealt with bug 510627. It looks like that was intended to be WinMo-only, though it had a rough landing so maybe some of the post-landing fixups were not quite right. I'll do some build bisecting to see where blame lies.
Checked the regression range for mozilla-central, dougt suggests bug 475595 may be the more likely cause, and it landed on a different day than 511167. trunk 08-27-03 nightly is ok. trunk 08-28-03 nightly is ok. trunk 09-14-03 nightly is ok. trunk 09-15-03 nightly is bad. Regression range on trunk: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=912c6ae3b70c&tochange=cdcf1519121f Bug 475595 and bug 515818 are the only common bugs in these two regression range.
Confirmed that this is bug 475595... Commenting out the calls to GlobalMemoryStatus() in IsLowMemory() [and returning PR_FALSE instead] made the browser fast again. The comment is also a dead giveaway. :-/ 118 #if defined(WINCE) 119 *result = PR_FALSE; 120 // See bug 475595 -- this is incorrect right now, and causes a big 121 // perf hit since GlobalMemoryStatus has to grab a kernel VM lock 122 // and do a bunch of munging through VM pages to get the data 123 // that's requested. We call IsLowMemory in some performance 124 // critical code (e.g. during painting), so that's bad. 125 MEMORYSTATUS stat; 126 GlobalMemoryStatus(&stat); 127 *result = (stat.dwMemoryLoad >= 98); 128 #elif defined(XP_WIN)
Target Milestone: --- → Firefox 3.7a1
Needs a better long term solution, but I think we should land this ASAP to make nightlies usable again.
Attachment #409476 - Flags: review?(vladimir)
Comment on attachment 409476 [details] [diff] [review] Patch v.1 can you only return FALSE on WINCE, and just make what it currently is doing WINCE_WINDOWS_MOBILE. For whatever reason, i am not seeing a terrible perf problem on windows mobile 6.5.
Attachment #409476 - Flags: review?(vladimir) → review-
Patch to leave it as-is on WinMo, but disabled on WinCE. Vlad r+a192'd this via email from a hockey game, so I'll check it in now. :)
Attachment #409476 - Attachment is obsolete: true
Pushed http://hg.mozilla.org/mozilla-central/rev/8132c52d4dee Pushed to 192: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/c3a3d758db0e Do we need a followup bug to implement something real here?
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment on attachment 409477 [details] [diff] [review] Patch v.2 We could look at a followup bug, but I'm not too worried about doing so.
Thanks for the quick fix. Going to grab the latest nightly to take it for a whirl.
Verified fixed using Mozilla/5.0 (Windows; U; WindowsCE 6.0; en-US; rv:1.9.2b2pre) Gecko/20091031 Namoroka/3.6b2pre. Build runs much smoother. Adding keyword.
i concur the build is now in a usable and responsive state. verifying on trunk: Mozilla/5.0 (Windows; U; WindowsCE 6.0; en-US; rv:1.9.3a1pre) Gecko/20091031 Minefield/3.7a1pre the only thing though, its crashy. i had to restart 3 times here on bugzilla. but will investigate more and track in another bug.
Status: RESOLVED → VERIFIED
Already fixed, but we would have held the release to understand why WinCE was unusable, marking this blocking+ for bookkeeping.
Flags: blocking-firefox3.6? → blocking-firefox3.6+
I noticed that there may be a bug in the original implementation: dwLength of struct MEMORYSTATUS should be initialized before calling GlobalMemoryStatus MEMORYSTATUS stat; + stat.dwLength = sizeof(stat); GlobalMemoryStatus(&stat); BTW: I'm not sure if this caused the problem, but I'm goint to use a Win32 Timer to track memory in my private build.
Just FYI, the timer-based patch is working on my CE 6 device well. Once the free memory hitted the limit, all graphics rendering was stopped, and I could stop firefox without crashing. I used dwAvailPhys other than dwMemoryLoad, which may be more precise.
You need to log in before you can comment on or make changes to this bug.