Closed
Bug 698644
Opened 14 years ago
Closed 3 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•14 years ago
|
||
Never mind, its not just OnDispatch, its also the context pushing.
Reporter | ||
Comment 2•14 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•14 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•14 years ago
|
||
Yeah I have a new patch will upload when I find network.
Reporter | ||
Comment 7•14 years ago
|
||
Attachment #570897 -
Attachment is obsolete: true
Comment 8•14 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•3 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•3 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: 3 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•