455820 - cnn.com pegs cpu

Status: VERIFIED WORKSFORME

(Firefox for Android Graveyard :: General, defect)

Description

[Doug Turner (:dougt)]

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

I have disabled plugins.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

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...

Comment 2

[Doug Turner (:dougt)]

jeff, does it go away if you disable plugins?

Comment 3

[Jeff Muizelaar [:jrmuizel]]

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...

Comment 4

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 5

[Jeff Muizelaar [:jrmuizel]]

About 60% of the time is spent in:
mozInlineSpellWordUitl::SplitDOMWord()
|- WordSplitState::FindSpecialWord()

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

Comment 6

[Doug Turner (:dougt)]

why is spell check even engaged when loading cnn?

Comment 7

[:Gavin Sharp [email: [e-mail]]]

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

see comment 3.

Comment 8

[Jeff Muizelaar [:jrmuizel]]

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...

Comment 9

[Jeff Muizelaar [:jrmuizel]]

It seems the spell checking problem is much worse when building with --enable-debug...

Comment 10

[Jeff Muizelaar [:jrmuizel]]

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%

Comment 11

[(not currently active) Ted Mielczarek]

Is the textarea in a hidden iframe or something? Maybe we could figure out a way to not spellcheck hidden textareas?

Comment 12

[Brad Lassey [:blassey] (use needinfo?)]

according to top, Fennec b2 is sits above 90% of cpu with cnn loaded and not interacting with the page.  Reopening.

Comment 13

[Doug Turner (:dougt)]

brad, do you see this still?

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

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.

Comment 15

[Ben Combee (:bcombee)]

Brad, can you try disabling plugins?  I remember cnn.com having a lot of Flash content, and that tends to peg the CPU.

Comment 16

[Brad Lassey [:blassey] (use needinfo?)]

(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%.

Comment 17

[Brad Lassey [:blassey] (use needinfo?)]

with the 11/3 nightly cpu usage is 10-30%

Comment 18

[Joel Maher ( :jmaher ) (UTC -8) (PTO'ish until July 5)]

verified with 20091106 nightly build on n810