Some insight into perf issue in Netmonitor

[Ricky Chien]

Hey everyone,

As you may know, Netmonitor has hit perf regression after de-XUL and react
redux rewrite. It's
slow when loading large complicated website like CNN or BBC.
​ The phenomenon of dropping FPS is also obvious when scrolling in request
list loading a large amount of network requests.
Here are some my observations
​. Any feedback and inputs are
welcome.

*​Key factor​​s​ that​ affect to performance​:*

- ​
​Too many request elements are rendered in netmonitor panel.
- ​Especially in

​visiting

​large and ​
complicated website
​ like http://www.cnn.com​
​ or
http://www.bbc.com
​.
- User might feel the rendering is stutter when resizing panel height
or width.
- Waterfall column redraws frequently when every new request arrives.
- Waterfall timelines are constructed by div, the position and width of
each div will be changed accordingly.
- ​Devtools toolbox is running on chrome (parent) process​ rather
than a standalone content (child) process.

- That's why running netmonitor on launchpad (content process) is
smoother than toolbox (chrome process).
- *Toolbox is slow*. Other devtools panels have great influence with
performance as well, even there is only one netmonitor panel is active but
others are inactive.
- After striping off other panels and loading netmonitor panel via
about:devtools-toolbox
​, we can see netmonitor is still running on chrome process but its
performance is as fast as running on launchpad.
- ​Current way of dispatching actor event​ to update UI doesn't fit
the newer react redux architecture.

- The design of sending "netw
orkEvent" and "networkEventUpdate" will cause highly frequent update
​in​
redux state. It implies more times
​the​
store.subscribe listener will be invoked. We should take a bit more
care with dispatching action. To avoid dispatching too many actions in a
short period of time, we can queue
​ these additional "networkEventUpdate" packets before dispatching
action, and then merge them into one single payload to reduce the number
of action dispatching
​. (See also *​*
<https://bugzilla.mozilla.org/show_bug.cgi?id=1358715>
*bug 1358715* <https://bugzilla.mozilla.org/show_bug.cgi?id=1358715>
*​*)​.

*Solution:*

- ​​
Introduce React-virtualized
​ (*Bug * <https://bugzilla.mozilla.org/show_bug.cgi?id=1308441>
*1308441 <https://bugzilla.mozilla.org/show_bug.cgi?id=1308441>*
*​)*​
​
- Patch is ready but unfortunately it’s blocked by APZ issue.
- ​In order to mitigate perf issue when visiting large website,
reducing amount of request elements on panel is the key
performance ​factor.

- It also reduce the number of waterfall timings elements rendering
on the page.
- Resizing panel height and width will be smoother and responsive.
- ​Use canvas to refactor waterfall column (*Bug - 1308695*
<https://bugzilla.mozilla.org/show_bug.cgi?id=1308695>)

- ​Drawing a large amount of div elements for timeline information is
high consumption

- ​Introduce column resize​r (*Bug 1358414*
<https://bugzilla.mozilla.org/show_bug.cgi?id=1358414>) and read column
width from prefs

- Obvious frame drop when scrolling is due to frequent waterfall
timelines reflow. Given a fixed waterfall column width which loads from
prefs is a beneficial approach to reduce the frequency of reflow
when panel
width resizing.
- ​Load devtools in a separate content process​.
- Chromium is running its devtools via a separate process as well.
- ​Find out the root cause for why ​other panels impact on netmonitor
in toolbox, even though these panels are inactive.

- The root cause of this issue is still uncertain. Probably there are
more extra actors or tasks running in background when toolbox is started.

Ongoing panel refactoring like console might be under the
influence
of the same perf issue
​ as well. ​I think this lesson we learned from netmonitor rewrite can give
some
caveats
​and ​
​
insight.
​ Feel free to ask questions and provide your opinions. ​I'm willing to
share more experiences about this.

Cheers.

[Jan Odvarko]

This is great summary Ricky!

My vote goes to the the waterfall graph. I think that refactoring the
Timeline column
could be great next and effective step to improve Net panel's performance.

Honza

[Brian Grinstead]

Thanks for bringing this up Ricky,
We are having similar issues with the console and are currently working
through some bottlenecks. But your point about code running in the toolbox
being slow is true - we shouldn't have to resort to virtualization or other
workarounds to display a couple of thousand DOM nodes when we don't need to
do that while running the same page in a tab.

I'm not sure if it's explicitly being in the toolbox that's slowing it down
though - for instance, if you add an <iframe> directly in browser.xul
loading the same about:devtools-toolbox uri, do you see similar performance
as with the toolbox or closer to a tab? What about opening it via
Services.ww.openWindow? I'm planning to spend some time looking into this
mysterious slowness as part of the new console work so l hope we can work
together to figure out a fix that will apply to both.

Brian

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools
>

[Brian Grinstead]

One more thing to check as well - do you see the same slowness when the
toolbox is popped out as a window instead of docked to the bottom of the
page?

On Mon, May 1, 2017 at 10:06 AM, Brian Grinstead <bgrin...@mozilla.com>
wrote: