Re: Quantum Flow Engineering Newsletter #6

[Chris Peterson]

btw, Nathan Froyd is working to add Gecko Profiler support for Stylo's 
Rust code and rayon threads in bug 1322656.



On 2017-04-21 8:50 AM, Ehsan Akhgari wrote:

On 04/21/2017 03:12 AM, Nicholas Nethercote wrote:

Judging from the incoming flow of bug reports, the number of people
using the Gecko Profiler has increased in the last week or two. I take
this as a good sign that it's being used increasingly heavily for
Quantum Flow work, which is good.

Yes, indeed.  I should also say that this is definitely due to the hard
work of everyone working on improving it both the backend side and on
the UI side (including you!)  It's safe to say that this push on
performance could not have happened without the Gecko Profiler, so
thanks to everyone who keeps making it better.



Nick

On Fri, Apr 21, 2017 at 4:25 PM, Ehsan Akhgari
> wrote:

Hi everyone,

I would like to share some updates about some of the ongoing
performance related work.

We have started looking at the native stack traces that are
submitted through telemetry from the Background Hang Reports that
take more than 8 seconds.  (We were hoping to have been able to
reduce this threshold to 256ms
 for a while
now, but the road has been bumpy -- but this should land really
soon now!)  Michael Layzell put together a telemetry analysis job
that creates a symbolicated version of this data here:
https://people-mozilla.org/~mlayzell/bhr/
. For example, this
 is the
latest generated report.  The grouping of this data is
unfortunate, since the data is collected based on the profiler
pseudo-stack labels, which is captured after 128ms, and then
native stack (if the hang continues for 8 seconds) gets captured
after that, so the pseudo-stack and the native stack may or may
not correspond, and this grouping also doesn't help going through
the list of native stacks and triage them more effectively.  Work
is under way to create a nice dashboard
 out of this
data, but in the mean time this is an area where we could really
use all of the help that we can get.  If you have some time, it
would be really nice if you can take a look at this data and see
if you can make sense of some of these call stacks and find some
useful bug reports out of them.  If you do end up filing bugs,
these are super important bugs to work on, so please make sure you
add "[qf]" to the status whiteboard so that we can track the bug.

Another item worthy of highlight is Mike Conley's Oh No! Reflow!
add-on .  Don't let the
simple web page behind this link deceive you, this add-on is
really awesome!  It generates a beep every time that a long
running reflow happens in the browser UI (which, of course, you
get to turn off when you don't need to hunt for bugs!), and it
logs the sync reflows that happened alongside the JS call stack to
the code that triggered them, and it also gives you a single link
that allows you to quickly file a bug with all of the right info
in it, pre-filled!  In fact you can see the list of already filed
bugs



through this add-on!

Another issue that I want to bring up is the [qf:p1] bugs.  As you
have noticed, there are a lot of them. :-)  It is possible that
some of these bugs aren't important to work on, for example
because they only affect edge case conditions that affects a super
small subset of users and that wasn't obvious when the bug was
triaged.  In some other cases it may turn out that fixing the bug
requires massive amounts of work that is unreasonable to do in the
amount of time we have, or that the right people for it are doing
more important work and can't be interrupted, and so on.  Whatever
the issue is, whether the bug was mis-triaged, or can't be fixed,
please make sure to raise it on the bug!  In general the earlier
these issues are uncovered the better it is, because everyone can
focus their time on more important work.  I wanted to make sure
that this wasn't lost in all of the rush around our communication
for Quantum Flow, my apologies if this hasn't been clear before.


On to the acknowledgement section, I hope I'm not forgetting to
mention anyone's name here!

  * Bas Schouten made it so that we don't clear the compositor
background immediately before drawing into it
. This
made some painting and scrolling related benchmarks faster

Re: Quantum Flow Engineering Newsletter #6

[Ehsan Akhgari]

On 04/21/2017 03:12 AM, Nicholas Nethercote wrote:
Judging from the incoming flow of bug reports, the number of people 
using the Gecko Profiler has increased in the last week or two. I take 
this as a good sign that it's being used increasingly heavily for 
Quantum Flow work, which is good.
Yes, indeed.  I should also say that this is definitely due to the hard 
work of everyone working on improving it both the backend side and on 
the UI side (including you!)  It's safe to say that this push on 
performance could not have happened without the Gecko Profiler, so 
thanks to everyone who keeps making it better.




Nick

On Fri, Apr 21, 2017 at 4:25 PM, Ehsan Akhgari 
> wrote:


Hi everyone,

I would like to share some updates about some of the ongoing
performance related work.

We have started looking at the native stack traces that are
submitted through telemetry from the Background Hang Reports that
take more than 8 seconds.  (We were hoping to have been able to
reduce this threshold to 256ms
 for a while
now, but the road has been bumpy -- but this should land really
soon now!)  Michael Layzell put together a telemetry analysis job
that creates a symbolicated version of this data here:
https://people-mozilla.org/~mlayzell/bhr/
. For example, this
 is the
latest generated report.  The grouping of this data is
unfortunate, since the data is collected based on the profiler
pseudo-stack labels, which is captured after 128ms, and then
native stack (if the hang continues for 8 seconds) gets captured
after that, so the pseudo-stack and the native stack may or may
not correspond, and this grouping also doesn't help going through
the list of native stacks and triage them more effectively.  Work
is under way to create a nice dashboard
 out of this
data, but in the mean time this is an area where we could really
use all of the help that we can get.  If you have some time, it
would be really nice if you can take a look at this data and see
if you can make sense of some of these call stacks and find some
useful bug reports out of them.  If you do end up filing bugs,
these are super important bugs to work on, so please make sure you
add "[qf]" to the status whiteboard so that we can track the bug.

Another item worthy of highlight is Mike Conley's Oh No! Reflow!
add-on .  Don't let the
simple web page behind this link deceive you, this add-on is
really awesome!  It generates a beep every time that a long
running reflow happens in the browser UI (which, of course, you
get to turn off when you don't need to hunt for bugs!), and it
logs the sync reflows that happened alongside the JS call stack to
the code that triggered them, and it also gives you a single link
that allows you to quickly file a bug with all of the right info
in it, pre-filled!  In fact you can see the list of already filed
bugs


through this add-on!

Another issue that I want to bring up is the [qf:p1] bugs.  As you
have noticed, there are a lot of them. :-)  It is possible that
some of these bugs aren't important to work on, for example
because they only affect edge case conditions that affects a super
small subset of users and that wasn't obvious when the bug was
triaged.  In some other cases it may turn out that fixing the bug
requires massive amounts of work that is unreasonable to do in the
amount of time we have, or that the right people for it are doing
more important work and can't be interrupted, and so on.  Whatever
the issue is, whether the bug was mis-triaged, or can't be fixed,
please make sure to raise it on the bug!  In general the earlier
these issues are uncovered the better it is, because everyone can
focus their time on more important work.  I wanted to make sure
that this wasn't lost in all of the rush around our communication
for Quantum Flow, my apologies if this hasn't been clear before.


On to the acknowledgement section, I hope I'm not forgetting to
mention anyone's name here!

  * Bas Schouten made it so that we don't clear the compositor
background immediately before drawing into it
. This
made some painting and scrolling related benchmarks faster
,
and fixed a flickering issue

Re: Quantum Flow Engineering Newsletter #6

[Nicholas Nethercote]

Judging from the incoming flow of bug reports, the number of people using
the Gecko Profiler has increased in the last week or two. I take this as a
good sign that it's being used increasingly heavily for Quantum Flow work,
which is good.

Nick

On Fri, Apr 21, 2017 at 4:25 PM, Ehsan Akhgari 
wrote:

> Hi everyone,
>
> I would like to share some updates about some of the ongoing performance
> related work.
>
> We have started looking at the native stack traces that are submitted
> through telemetry from the Background Hang Reports that take more than 8
> seconds.  (We were hoping to have been able to reduce this threshold to
> 256ms  for a while
> now, but the road has been bumpy -- but this should land really soon now!)
> Michael Layzell put together a telemetry analysis job that creates a
> symbolicated version of this data here: https://people-mozilla.org/~
> mlayzell/bhr/.  For example, this
>  is the latest
> generated report.  The grouping of this data is unfortunate, since the data
> is collected based on the profiler pseudo-stack labels, which is captured
> after 128ms, and then native stack (if the hang continues for 8 seconds)
> gets captured after that, so the pseudo-stack and the native stack may or
> may not correspond, and this grouping also doesn't help going through the
> list of native stacks and triage them more effectively.  Work is under way
> to create a nice dashboard
>  out of this data,
> but in the mean time this is an area where we could really use all of the
> help that we can get.  If you have some time, it would be really nice if
> you can take a look at this data and see if you can make sense of some of
> these call stacks and find some useful bug reports out of them.  If you do
> end up filing bugs, these are super important bugs to work on, so please
> make sure you add "[qf]" to the status whiteboard so that we can track the
> bug.
>
> Another item worthy of highlight is Mike Conley's Oh No! Reflow! add-on
> .  Don't let the simple web
> page behind this link deceive you, this add-on is really awesome!  It
> generates a beep every time that a long running reflow happens in the
> browser UI (which, of course, you get to turn off when you don't need to
> hunt for bugs!), and it logs the sync reflows that happened alongside the
> JS call stack to the code that triggered them, and it also gives you a
> single link that allows you to quickly file a bug with all of the right
> info in it, pre-filled!  In fact you can see the list of already filed
> bugs
> 
> through this add-on!
>
> Another issue that I want to bring up is the [qf:p1] bugs.  As you have
> noticed, there are a lot of them.  :-)  It is possible that some of these
> bugs aren't important to work on, for example because they only affect edge
> case conditions that affects a super small subset of users and that wasn't
> obvious when the bug was triaged.  In some other cases it may turn out that
> fixing the bug requires massive amounts of work that is unreasonable to do
> in the amount of time we have, or that the right people for it are doing
> more important work and can't be interrupted, and so on.  Whatever the
> issue is, whether the bug was mis-triaged, or can't be fixed, please make
> sure to raise it on the bug!  In general the earlier these issues are
> uncovered the better it is, because everyone can focus their time on more
> important work.  I wanted to make sure that this wasn't lost in all of the
> rush around our communication for Quantum Flow, my apologies if this hasn't
> been clear before.
>
>
> On to the acknowledgement section, I hope I'm not forgetting to mention
> anyone's name here!
>
>
>- Bas Schouten made it so that we don't clear the compositor
>background immediately before drawing into it
>.  This made
>some painting and scrolling related benchmarks faster
>, and fixed
>a flickering issue
> in the mean
>time!
>- Mason Chang made the Youtube settings widget less janky
> on Windows with
>D2D when the video is fullscreen.
>- David Baron made the flushes caused by the code that watches your
>mouse to know which side of the window to put the status bar when you hover
>a link less severe
>.
>- Neil Deakin removed a synchronous layout flush
> that used to
>happen when closing a 

Quantum Flow Engineering Newsletter #6

[Ehsan Akhgari]

Hi everyone,

I would like to share some updates about some of the ongoing performance
related work.

We have started looking at the native stack traces that are submitted
through telemetry from the Background Hang Reports that take more than 8
seconds.  (We were hoping to have been able to reduce this threshold to
256ms  for a while
now, but the road has been bumpy -- but this should land really soon now!)
Michael Layzell put together a telemetry analysis job that creates a
symbolicated version of this data here:
https://people-mozilla.org/~mlayzell/bhr/.  For example, this
 is the latest
generated report.  The grouping of this data is unfortunate, since the data
is collected based on the profiler pseudo-stack labels, which is captured
after 128ms, and then native stack (if the hang continues for 8 seconds)
gets captured after that, so the pseudo-stack and the native stack may or
may not correspond, and this grouping also doesn't help going through the
list of native stacks and triage them more effectively.  Work is under way
to create a nice dashboard
 out of this data,
but in the mean time this is an area where we could really use all of the
help that we can get.  If you have some time, it would be really nice if
you can take a look at this data and see if you can make sense of some of
these call stacks and find some useful bug reports out of them.  If you do
end up filing bugs, these are super important bugs to work on, so please
make sure you add "[qf]" to the status whiteboard so that we can track the
bug.

Another item worthy of highlight is Mike Conley's Oh No! Reflow! add-on
.  Don't let the simple web page
behind this link deceive you, this add-on is really awesome!  It generates
a beep every time that a long running reflow happens in the browser UI
(which, of course, you get to turn off when you don't need to hunt for
bugs!), and it logs the sync reflows that happened alongside the JS call
stack to the code that triggered them, and it also gives you a single link
that allows you to quickly file a bug with all of the right info in it,
pre-filled!  In fact you can see the list of already filed bugs

through this add-on!

Another issue that I want to bring up is the [qf:p1] bugs.  As you have
noticed, there are a lot of them.  :-)  It is possible that some of these
bugs aren't important to work on, for example because they only affect edge
case conditions that affects a super small subset of users and that wasn't
obvious when the bug was triaged.  In some other cases it may turn out that
fixing the bug requires massive amounts of work that is unreasonable to do
in the amount of time we have, or that the right people for it are doing
more important work and can't be interrupted, and so on.  Whatever the
issue is, whether the bug was mis-triaged, or can't be fixed, please make
sure to raise it on the bug!  In general the earlier these issues are
uncovered the better it is, because everyone can focus their time on more
important work.  I wanted to make sure that this wasn't lost in all of the
rush around our communication for Quantum Flow, my apologies if this hasn't
been clear before.


On to the acknowledgement section, I hope I'm not forgetting to mention
anyone's name here!


   - Bas Schouten made it so that we don't clear the compositor background
   immediately before drawing into it
   .  This made some
   painting and scrolling related benchmarks faster
   , and
fixed a flickering
   issue  in the mean
   time!
   - Mason Chang made the Youtube settings widget less janky
    on Windows with
   D2D when the video is fullscreen.
   - David Baron made the flushes caused by the code that watches your
   mouse to know which side of the window to put the status bar when you hover
   a link less severe 
   .
   - Neil Deakin removed a synchronous layout flush
    that used to
   happen when closing a window which would slow down the window going away.
   - Dão Gottwald removed some obsolete tab animation telemetry
    which could slow
   down tab animations (yes!).  Dão also removed a synchronous layout flush
    which could slow
   down detaching a tab into a new window and he also lazified some
code to avoid
   some more layout flushes