Thanks for the clarification, Olli. We're in a bit of a transition process
of moving the addon's implementation into mozilla central with a direct
integration. I'll try to prioritize finishing up that transition as it's a
bit confusing as new features are landing in the popup, but not in the
addon right now.

On Wed, Oct 30, 2019 at 4:50 PM smaug <> wrote:

> FWIW, apparently the UI is in the devtools profiler UI, not in the
> profiler addon.
> still tells users to install the addon from
> there.
> I was told that one can get the button similar to the addon by enabling
> devtools.performance.popup.enabled boolean pref and then using
> 'Customize...'
> Anyhow, great stuff. Seeing IPC messages in the profiles can be really
> handy.
> (and so far I've been positively surprised that we don't seem to send that
> many IPC messages)
> -Olli
> On 10/30/19 10:14 PM, Jim Porter wrote:
> > Recently, we landed a new feature for the Firefox Profiler: the ability
> to record IPC messages for monitored threads. This should be useful for
> > evaluating IPC-related performance issues as we make progress on Project
> Fission. To enable this feature, just check the "IPC Messages" feature in
> the
> > profiler popup and collect a profile! Then, IPC messages on all
> monitored threads will be recorded to the profile.
> >
> > For an example of what this looks like, see this profile of a user (me)
> opening in a new tab: <>.
> >
> > Since IPC messages are (obviously) cross-process, each IPC message is
> actually comprised of two profiler markers: one for the sending thread and
> one
> > for the receiving thread. The profiler frontend then examines all the
> collected IPC markers and correlates the sending and receiving sides. After
> > correlating each side, we can then determine the latency of the IPC
> message: this is defined to be the time between when the message is sent
> (i.e.
> > when `SendMessage` or similar is called) and when it's received (i.e.
> once the recipient thread has constructed a `Message` object).
> >
> > Sometimes, IPC messages will have an unknown duration. This means that
> the profiler marker for the other side of the IPC call wasn't recorded
> (either
> > the thread wasn't profiled at all or the other side occurred outside of
> the time range of the profile).
> >
> > As you can probably see from the example profile, the user interface is
> fairly basic for now: each thread just has a new timeline track to display
> its
> > IPC messages, with outgoing messages in teal and incoming messages in
> purple. Of course, there's lots of room for improvement here, so if you
> have
> > ideas for a visualization that would be useful to you, just file a bug
> and CC me on it!
> >
> > Happy profiling!
> > - Jim
> >
> > P.S.: For those who are curious about how we correlate each side of an
> IPC message, we compare the source and destination PIDs, the message's
> type,
> > and its seqno. This is enough to uniquely identify any IPC message,
> though it does mean that reply messages are considered a separate message.
> If
> > people find it useful, it should be straightforward to correlate initial
> and reply messages with each other as well.
> _______________________________________________
> dev-platform mailing list
dev-platform mailing list

Reply via email to