Status

Firefox for Android Graveyard
General
VERIFIED WORKSFORME
10 years ago
9 years ago

People

(Reporter: dougt, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
fennec1.0a1
Bug Flags:
blocking-xul-fennec1.0 +

Details

(Reporter)

Description

10 years ago
after loading cnn.com, it looks like the cpu is pegged.  (look with htop)

I have disabled plugins.
Nothing jumps out. We seem to be all over the code. I did notice the cycle collector coming up a few times. I don't know whether that is expected or not...
(Reporter)

Comment 2

10 years ago
jeff, does it go away if you disable plugins?
We seem to spend post-load pegging the cpu spellchecking http://svcs.cnn.com/weather/getForecast?mode=json_html&zipCode=79031&csiID=csi3 which is included in an iframe on the cnn front page. I'm not sure why spell checking is so much more expensive for us yet...
One theory that jeff and I talked about was that spellcheck might be generating so many repaint events (for the squigglies) that cost of event dispatch and/or the work done in the fennec listener was just overwhelming.
About 60% of the time is spent in:
mozInlineSpellWordUitl::SplitDOMWord()
|- WordSplitState::FindSpecialWord()

Another 20% is in:
mozInlineSplellChecker::RemoveRange()
|- nsTypedSelection::RemoveRange()
   |- nsTypedSelection::selectFrames()
      |- nsTextFrame::SetSelected()
(Reporter)

Comment 6

10 years ago
why is spell check even engaged when loading cnn?
(In reply to comment #6)
> why is spell check even engaged when loading cnn?

see comment 3.
SplitDOMWord() is called by BuildRealWords() which seems to iterate over the entire textarea contents (14 thousand characters or so for cnn) every time DoSpellCheck is called. This seems odd if we are trying to do incremental spell checking...
It seems the spell checking problem is much worse when building with --enable-debug...

Updated

10 years ago
Flags: blocking-fennec1.0+
Target Milestone: --- → Fennec A1
Some new information from profiling in vmware with xephyr running in 16bit mode with pixman compiled with mmx support (this should give an environment that is roughly similar to on the n810)

We seem to be spending a lot of time in:

 nsDocLoader::doStopDocumentLoad() 34%
  ...
    js_Invoke() 14%
      js_NativeGet 5.5%
      js_str_match 4%
    XPC_WN_CallMethod() 11.8%
      DrawWindow() 7.58%
        PaintBackground 2.3%

In the xserver (23.9%) we are spending all of the time in pixman:
  pixman_image_composite 13.7%
  pixman_fill 4.37%
  pixman_rasterize_trapezoid 1.46%

Updated

10 years ago
Depends on: 441364
Is the textarea in a hidden iframe or something? Maybe we could figure out a way to not spellcheck hidden textareas?

Updated

9 years ago
tracking-fennec: --- → 1.0+

Updated

9 years ago
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
according to top, Fennec b2 is sits above 90% of cpu with cnn loaded and not interacting with the page.  Reopening.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(Reporter)

Comment 13

9 years ago
brad, do you see this still?
according to top loading cnn, the cpu stays around 95-97 for fennec for about a minute after the page loads.  After a while it falls to 85%, which still seems too high.
Brad, can you try disabling plugins?  I remember cnn.com having a lot of Flash content, and that tends to peg the CPU.
(In reply to comment #15)
> Brad, can you try disabling plugins?  I remember cnn.com having a lot of Flash
> content, and that tends to peg the CPU.

disabling plugins we still hit 97% for a few seconds after the page has loaded but we then quickly drop down to 2%.
with the 11/3 nightly cpu usage is 10-30%
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → WORKSFORME
verified with 20091106 nightly build on n810
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.