Closed
Bug 698644
Opened 13 years ago
Closed 2 years ago
Measure event loop latency
Categories
(Core :: XPConnect, defect)
Core
XPConnect
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: gal, Unassigned)
Details
Attachments
(1 file, 1 obsolete file)
2.59 KB,
patch
|
Details | Diff | Splinter Review |
Looks to me that all we need that for these days is to keep XPConnect around, which can do with addref/release just as well.
Reporter | ||
Comment 1•13 years ago
|
||
Never mind, its not just OnDispatch, its also the context pushing.
Reporter | ||
Comment 2•13 years ago
|
||
In which case I can re-purpose this code nicely.
Summary: Why does XPConnect use NS_SetGlobalThreadObserver? → Measure event loop latency
Reporter | ||
Comment 3•13 years ago
|
||
We want to know when an event takes a long time to process, minus processing of content script. I will put some measurement into xpconnect On/AfterProcessNextEvent and cancel the measurement if content script runs.
Comment on attachment 570897 [details] [diff] [review] patch Review of attachment 570897 [details] [diff] [review]: ----------------------------------------------------------------- I know this isn't expecting review or anything but I wanted to point out two things before anyone tries it. ::: js/xpconnect/src/nsXPConnect.cpp @@ +2355,5 @@ > nsXPConnect::OnProcessNextEvent(nsIThreadInternal *aThread, bool aMayWait, > PRUint32 aRecursionDepth) > { > + EventProcessingTiming timing = { current, PR_Now() }; > + current = &timing; This won't work, you're taking address of stack var that you're about to paint over when this function exits. @@ +2374,5 @@ > > + nsresult rv = Pop(nsnull); > + > + PRTime now = PR_Now(); > + long ms = (now = current->start) / PR_USEC_PER_MSEC; Should be |(now - current->start)|
Reporter | ||
Comment 6•13 years ago
|
||
Yeah I have a new patch will upload when I find network.
Reporter | ||
Comment 7•13 years ago
|
||
Attachment #570897 -
Attachment is obsolete: true
Comment 8•13 years ago
|
||
Note that these global observers only run on *XPCOM* events: the widget thread observer actually does the blocking on native-or-XPCOM events and may dispatch many (or no) native events for each iteration of the main XPCOM event loop (nsThread::ProcessNextEvent). So we really need the instrumentation at the widget layer (or to revamp our main event dispatch mechanism) instead of at the XPCOM layer. The data here won't be especially useful, I think.
Comment 9•2 years ago
|
||
The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.
Assignee: gal → nobody
Comment 10•2 years ago
|
||
We have other mechanisms like the Background Hang Monitor for measuring event latency nowadays, so I don't think we're going to do anything with this at this point.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•