Tim Taubert [:ttaubert] (inactive) Reporter
	Description • 10 years ago

Resuming from suspend, I found that Nightly feels quite slow when typing and seems to consume a constant amount of ~20% of CPU. Measuring with the profiler add-on it finds that 95% of the times is spent in:

[NSApp nextEventMatchingMask:NSAnyEventMask:untilDate:inMode:dequeue:]

Looking at the changeset from bug 996848 this seems related as well. Here is the profile from where I have a few tabs open but didn't do anything other than just looking at an idle page:

https://people.mozilla.org/~bgirard/cleopatra/#report=576514c9888ed30e9f1f249bc77b7436361562a8

	Tim Taubert [:ttaubert] (inactive) Reporter
	Comment 1 • 10 years ago

Sampling the process, it seems to spend 1.887s of 2.044s in mach_msg_trap. Not sure if that's a problem or not.

	Tim Taubert [:ttaubert] (inactive) Reporter
	Comment 2 • 10 years ago

No, that doesn't seem to be a problem, I think that's just a blocking call waiting for new events?

	Markus Stange [:mstange]
	Comment 3 • 10 years ago

-[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] being present in large parts of the profile isn't anything to be worried about by itself.
The constant CPU usage seems to come from lots of onload events firing, and from lots of refresh driver invocations. The permanent refresh driver load may be related to bug 759252 (and a platform bug that doesn't register stopped throbber animations, for example).
Bug 1015317 looks similar.

But what definitely points to bug 996848 is the fact that typing was slow for you. The profile shows that we frequently get back to the event loop idle state (__CFRunLoopServiceMachPort), at a rate that should be high enough to allow for responsive key event processing. If those key events don't get through, something's wrong.

	Markus Stange [:mstange]
	Comment 4 • 10 years ago

(In reply to Tim Taubert [:ttaubert] from comment #2)
> No, that doesn't seem to be a problem, I think that's just a blocking call
> waiting for new events?

Exactly.

	Tim Taubert [:ttaubert] (inactive) Reporter
	Comment 5 • 10 years ago

The CPU usage seems to be caused by throbber animations running in the background although they shouldn't. Will file a separate bug for that. I'll keep an eye out for slow typing but everything seems normal for now.

	Steven Michaud [:smichaud] (Retired)
	Comment 6 • 10 years ago

I expect that the patch for bug 996848 actually helped uncover this bug, by reducing nsIRunnable event starvation as you're typing.

In my experience typing has been "slow" in Firefox for a long time (since well before my patch for bug 996848 landed) ... though I regret to say I never opened a bug about it.

	Steven Michaud [:smichaud] (Retired)
	Comment 7 • 10 years ago

Someone should look at profiling stats focused on nsThread::ProcessNextEvent() (while typing and not typing), to see (at least roughly) which nsIRunnable events are responsible for the greatest increase in CPU usage while typing.