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 <sm...@welho.com> wrote: > FWIW, apparently the UI is in the devtools profiler UI, not in the > profiler addon. > https://profiler.firefox.com/ 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 mozilla.org in a new tab: <https://perfht.ml/2Wtkgx1>. > > > > 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@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
