179593 - Improve "normal" typing performance in mail Compose body

Status: RESOLVED INCOMPLETE

(Thunderbird :: Message Compose Window, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

Mozilla trunk, fresh pull/build today (11/11/02)
See bug 129857, though I don't think this is per-se a dup of that (it may be a
blocker for that).

Typing in the body area of a Compose window is expensive; apparently there's a
JS event listener on the Compose body.  I just did a (trunk) jprof on a VERY
fast Linux box, and while I didn't see a delay (this is a dual-2GHz Linux RH 7.x
box), I got a LOT of hits in jprof (~1200) after typing 2-3 paragraphs of
garbage.  On a low-spec machine this probably contributes to the apparent laggy
feel.

1121 nsEventListenerManager::HandleEvent():
   537 nsTextEditorKeyListener::KeyPress
       161 nsPlaintextEditor::InsertText
       246 nsViewManager::Refresh
        84 nsContainerFrame::ReflowChild
   485 nsEventListenerManager::HandleEventSubType, almost all of which is
nsJSContext::CallEventHandler(), which leads to:
       169 XPTC_InvokeByIndex
            61 nsComposerController::GetCommandStateWithParams
            24 nsXULCommandDispatcher::GetControllerForCommand
            17 nsXULElement::GetChildNodes
            14 nsXULElement::SetAttribute
            etc
       A bunch of support routines end up eating more than 25% of the total,
       such as CanAccess, NativeData2JS, js_LookupProperty, js_Interpret has
       34 hits, PrepareAndDispatch, etc.

Around 5% of HandleEvent() is in XBL: mostly
nsXBLWindowHandler::WalkHandlersInternal, and most of that is nsCOMPtr nonsense.

I haven't looked to see what's listening on keypresses in compose.

Do we need to get some of the other perf people in on this?

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Attachment: tar-gzipped (tgz) file of jprof

Comment 2

[Matthias Versen [:Matti]]

typing in the text-only compose window is slower if the last few days-3 weeks
(win2k and 1.2GHZ Athlon)

Comment 3

[Johnny Stenback (:jst)]

As always, Qantify data would be nice to have, way easier to read and understand
than jprof data...

Comment 4

[Randell Jesup [:jesup] (needinfo me)]

quantify is something most people don't have access to; jprof is SO much easier
to use for most of us.

Also, jprof (if you understand how to read it) is darn good.  If you're willing
to keep the datafile and re-run jprof to produce new HTML outputs, it's very
close to as good I believe (NOTE: I've never used quantify, but I've used nice
visual profilers on NT & OS/2 in the past).

Note: one thing it doesn't give you is call counts.

For people not familiar with jprof, see
http://www.mozilla.org/performance/jprof.html and
http://lxr.mozilla.org/mozilla/source/tools/jprof/README.html

Basically, the data I threw in here is what seemed interesting to me.  

For example this:

1121 nsEventListenerManager::HandleEvent():
   537 nsTextEditorKeyListener::KeyPress
       161 nsPlaintextEditor::InsertText
       246 nsViewManager::Refresh
        84 nsContainerFrame::ReflowChild

means: 

1121/1200 (93%) hits were in HandleEvent; of those 537 (44% of the total) were
in KeyPress; of those 161 (13%) were in InsertText, 246 (20%) were in Refresh,
and 84 (7%) were in ReflowChild.  Note I'm giving totals including children;
very few routines had many direct hits.

The really interesting part was that ~40% of the time used is in handling a JS
event listener, much of it in handling the switch into and out of JS.  the
number of hist in Refresh and in InsertText are also somewhat interesting.

Comment 5

[Ere Maijala (slow)]

Sorry for jumping in like this. Don't know if this is of any use, but anyway. I
gave Sleuth StopWatch a shot and saw some interesting things. In my sample 3848
ms was spent in nsHTMLEditor::TypedText(). Under that:

nsAutoPlaceHolderBatch::~nsAutoPlaceHolderBatch()  2237 ms
  nsEditor::EndPlaceHolderTransaction()  2237 ms
    nsEditor::EndUpdateViewBatch()  1967 ms
    nsEditor::ScrollSelectionIntoView()  268 ms
nsPlainTextEditor::TypedText()  1506 ms
  nsPlainTextEditor::InsertText()  1506 ms
    nsAutoRules::~nsAutoRules()  795 ms
      nsHTMLEditor::EndOperation()  795 ms
    nsHTMLEditRules::WillDoAction()  581 ms
    nsAutoRules::nsAutoRules()  196 ms
      nsHTMLEditor::StartOperation()  196 ms

If someone finds it useful, I can get line-by-line profiles of wanted methods.

Comment 6

[Joe Francis]

The first 4 methods in your trace all are calling into layout to do reflow. 
That's where most of the time is spent within the editor part of the call chain.
 There is also a large amount of time spent outside of the editor altogether
(over half).  I suspect the event system.

Comment 7

[L A Walsh]

am opening additional bug on this since bugzilla is "broken" and doesn't
allow modification of various fields by anyone other than a "super user" or,
occasionally, the bug submitter (i.e. I've gotten several messages saying a 
field couldn't be changed other than by bug submitteror a sufficiently 
empowered "super user".  For some fields this is not appropriate. Ex.
Severity: a given bug may be 'normal' on one's persons system, but it may be
severe on another.

Comment 8

[Matthias Versen [:Matti]]

No, it doesn't matter how it's on your system. 
major= major loss of function (that isn't true) and 
critical = crash or dataloss , blocker= blocks Mozilal development
There are good reasons why you can't change all fields of a bug. 
BTW: this will get 1.5- (I'm sure)

Comment 9

[Asa Dotzler [:asa]]

*** Bug 207580 has been marked as a duplicate of this bug. ***

Comment 10

[Wayne Mery (:wsmwk)]

safe to assume this still exists ??
if so, this should be reevaluated.

xref  Bug 188318 typing quickly causes high cpu usage

Comment 11

[Dan Mosedale (:dmosedale, :dmose)]

It certainly _might_ still exist, but given all the changes to the platform over time, I wouldn't have any particular confidence that it does.I have no doubt that someone with a profiler, the right expertise, and time to devote could find fruitful ways to improve composition performance, however.

Comment 12

[Ioana (away)]

I haven't experienced this issue in any of the current Firefox versions on Windows 7, Ubuntu 13.04 or Mac OS X 10.7 and 10.9.

Can anyone still reproduce this issue?

Comment 13

[Wayne Mery (:wsmwk)]

(In reply to Wayne Mery (:wsmwk) from comment #10)
> xref  Bug 188318 typing quickly causes high cpu usage

note bug 188318 is still open

Comment 14

[Ioana (away)]

(In reply to Wayne Mery (:wsmwk) from comment #13)
> (In reply to Wayne Mery (:wsmwk) from comment #10)
> > xref  Bug 188318 typing quickly causes high cpu usage
> 
> note bug 188318 is still open

Yes, but QA couldn't reproduce any performance issue with typing quickly locally (see comment #12), so we can't really help here.

If you have any guidelines on something more specific we can try, please let me know and we'll try to help.

Comment 15

[Wayne Mery (:wsmwk)]

Unless you did a profile, please leave qawanted on this bug.  _this_ bug is not about very high CPU - at least not based on early comments - so don't be fooled by my mention of bug 188318. I mentioned 188318 because a) it also needs evaluation and b) it is a contemporary of this bug. (Perhaps there is a direct correlation, but I didn't compare these bug's jprof logs and afaik no one has.)

afaict this bug is about efficiency, because comment 0 merely states "Typing in the body area of a Compose window is expensive ... and ... I didn't see a delay".  So nowhere in comment 0 (and even subsequent comments afaict) is it stated that there is a user detectable perf hit, or that there is high CPU for that matter.  So the qawanted is needed (for anyone, not just firefox team) because per whiteboard a new profile is needed to compare against comment 0.  If that is what you did, then this bug should be closed. (and perhaps the same data can be used to evaluate bug 188318 )