Measure event loop latency

Assigned to



7 years ago
2 years ago


(Reporter: gal, Assigned: gal)



Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



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

Comment 1

7 years ago
Never mind, its not just OnDispatch, its also the context pushing.

Comment 2

7 years ago
In which case I can re-purpose this code nicely.
Summary: Why does XPConnect use NS_SetGlobalThreadObserver? → Measure event loop latency

Comment 3

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

7 years ago
Created attachment 570897 [details] [diff] [review]

Assignee: nobody → gal
Comment on attachment 570897 [details] [diff] [review]

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

Comment 6

7 years ago
Yeah I have a new patch will upload when I find network.

Comment 7

7 years ago
Created attachment 571070 [details] [diff] [review]
new patch
Attachment #570897 - Attachment is obsolete: true

Comment 8

7 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.
You need to log in before you can comment on or make changes to this bug.