Closed Bug 525323 Opened 10 years ago Closed 10 years ago

Windows CE ux/perf regression between Alpha 2 and Beta 1

Categories

(Firefox :: General, defect)

ARM
Windows CE
defect
Not set

Tracking

()

VERIFIED FIXED
Firefox 3.7a1
Tracking Status
status1.9.2 --- beta2-fixed

People

(Reporter: Dolske, Assigned: Dolske)

References

Details

(Keywords: verified1.9.2, Whiteboard: [nv])

Attachments

(1 file, 1 obsolete file)

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.
Flags: blocking-firefox3.6?
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)
Blocks: 475595
Target Milestone: --- → Firefox 3.7a1
Attached patch Patch v.1 (obsolete) — Splinter Review
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-
Attached patch Patch v.2Splinter 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.
Attachment #409477 - Flags: review+
Attachment #409477 - Flags: approval1.9.2+
Thanks for the quick fix. Going to grab the latest nightly to take it for a whirl.
Whiteboard: [nv]
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.
Keywords: verified1.9.2
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.