Project Candle bug triage (13th September 2015)

[Nicholas Nethercote]

Greetings,

PREAMBLE

This is a bug triage email for Project Candle. You are receiving it because
either (a) you have subscribed to the dev-power mailing list, or (b) you have
been CC'd because I have directly asked you a question below.

Project Candle is described on its wiki page:
https://wiki.mozilla.org/Performance/Project_Candle

The primary purpose of this email thread is to get eyes on bugs that have been
marked with the "[Power]" whiteboard marking and to triage them. If we can also
find people to do further investigation and/or assign themselves to a bug, even
better, though that is not expected to happen with every bug.

I briefly describe the bugs under consideration below, and have suggested a
priority level. Based on the discussion that follows, I will set the priority
of each of these bugs on Friday of this week.

This email thread is a substitute for the face-to-face meetings used by other
similar initiatives. Please take the time to click on the links for the bugs
below and look through them, and please feel free to speak up.


NOTES ABOUT THIS SPECIFIC THREAD

This is the first Project Candle triage discussion. The way these threads work
isn't yet established, and may require some tinkering. Please keep an open
mind. In particular, the wiki page describes the meaning of the three priority
levels (P1, P2, P3), and it might take some time to get a sense of how they are
used. Please feel free to make suggestions.

In this thread I am discussing only the 10 most recent bugs in the eligible bug
list. There are plenty more (50-something) that need triaging, and in future
email threads I may list more than 10, but for this first triage discussion I
thought I'd start with a relatively small number since we're all new to this
discussion process.


BUGS TO TRIAGE

* https://bugzilla.mozilla.org/show_bug.cgi?id=1190409
* investigate chrome graphics power improvements on mac

This is a speculative "we might be able to improve things" bug that is light on
specifics. There is one blocking bug that is also light on specifics.

I suggest P2.


* https://bugzilla.mozilla.org/show_bug.cgi?id=1190719
* High power usage on 8tracks.com

On Mac, for this music-playing site rapl says Firefox uses ~22.7 Watts, Safari
uses ~7.1 and Chrome uses ~5.8. Animation of a progress bar might be a factor.

I suggest P2, because it's not a widely-used site.


* https://bugzilla.mozilla.org/show_bug.cgi?id=1190721
* High power usage on businessinsider.com

On Mac we are slightly worse than Safari (rapl says ~4.1 Watts vs ~3.5 Watts).
An off-screen transform animation seems to be a factor; blocking bug 1166500
will hopefully fix that.

I suggest P3 because the difference with Safari is small.


* https://bugzilla.mozilla.org/show_bug.cgi?id=1190722
* High power usage on BuzzFeed

On Mac, we're much worse than Safari on the Buzzfeed front page: rapl says
~20.5 Watts vs. ~4.2 Watts. This is due to an invisible CSS animation that
triggers excessive display list building. Bug 1166500 is about fixing that
issue, and bbirtles is working on it.

I suggest P2 because BuzzFeed is popular but not, for example, YouTube-level
popular. (And I will suggest P1 for bug 1166500 when it comes up because it
will help on other sites.)


* https://bugzilla.mozilla.org/show_bug.cgi?id=1194049
* NsdManager increases power consumption

mfinkle found that NsdManager was the #3 power usage on his Nexus 5, using 6%.
xeonchen and schien are working on patches. I needinfo'd xeonchen to ask what
if there are any measurements with the patches applied.

I tentatively suggest P1 because it sounds like something that might affect
many Fennec users.


* https://bugzilla.mozilla.org/show_bug.cgi?id=1195790
* YouTube uses a lot more power in FF than Safari on OS X

On Mac, rapl says the following while playing a YouTube video: Firefox uses
~12.6 Watts, Safari uses ~7.5 Watts, and Chrome uses 11.9 Watts. (After those
measurements were made, bug 1195767 landed which reduced Firefox's usage by
~0.6 Watts.)

I suggest P1 because YouTube is so important. We should also see how we do on
YouTube on Windows and Android, though measurements are harder on those
platforms, esp. Android. If anyone can take those measurements on appropriate
hardware (i.e. not in a VM) and file bugs, that would be great. On Windows, I
suggest using Intel Power Gadget; on Android I'm not sure what the best way to
measure power consumption is.


* https://bugzilla.mozilla.org/show_bug.cgi?id=1197902
* Reduce the number of CCTimerFired wakeups

CCTimerFired wakeups happen up to four times per second, per process. It's not
a large number but it's something that's present across many workloads. mccr8
has ideas to reduce it, and a draft patch.

I suggest P2.


* https://bugzilla.mozilla.org/show_bug.cgi?id=1200028
* High CPU usage on a fujitsu-general.com page

On Windows, two people saw 100% CPU usage on this page on Windows. On Mac, rapl
says ~14.3 Watts processor+memory power usage compared with ~3.5 Watts for
Safari and ~4.3 Watts for Chrome.

So we're doing quite badly compared to other browsers but it's not a
high-exposure page. I suggest P2. See also bug 1203766 below, which has a
partial fix.


* https://bugzilla.mozilla.org/show_bug.cgi?id=1203427
* Add logging for timer firings

This bug has patches, awaiting review, that add logging to every timer firing.
The patches print the timer callback function. Timer firings trigger wakeups
and are a common cause of high power consumption. In the past both azakai and
rvitillo have found this kind of profiling to be effective, and the patches
build on their prior efforts.

I suggest P1, because this will likely get significant usage.


* https://bugzilla.mozilla.org/show_bug.cgi?id=1203766
* cache style contexts resolved by nsComputedDOMStyle for display:none elements

This bug has patches from heycam that avoid a lot of style context resolution
when looking at computed style objects for display:none elements, by using
caching. The patches mostly have r+ but need a few fix-ups. This reduces the
power consumption on Mac of the Fujitsu page mentioned above from ~14.6 Watts
to ~8 Watts, according to rapl.

This is a good result, but it's not clear if this fix will have wide
applicability. Therefore I suggest P2.

[Nicholas Nethercote]

Hello again,

There were no responses to the initial triage email, so I added
priorities as I suggested earlier. Details are below.

I'm not sure how to interpret the lack of response. I fear that this
email-based process may be fatally compromised by Warnock's Dilemma
(https://en.wikipedia.org/wiki/Warnock's_dilemma). But I will continue
trying it for at least a few weeks more.

Prioritising bugs is important, but probably what's more important is
simply getting multiple pairs of eyes on bugs. That leads to a higher
level of general awareness of the situation, e.g. where we are weak,
where we are improving. It also increases the likelihood that progress
will be made on a bug; you can't fix a bug you don't know about. So I
hope people actually clicked on the links and looked through the bugs.
I don't want these emails to be just one more thing that people
ignore, and I have no way of telling if that's the case.

So I'd be happy to hear feedback about this process. Thank you.

Nick

On Sun, Sep 13, 2015 at 9:31 PM, Nicholas Nethercote
<n.neth...@gmail.com> wrote:
>
> BUGS TO TRIAGE
>
> * https://bugzilla.mozilla.org/show_bug.cgi?id=1190409
> * investigate chrome graphics power improvements on mac
>
> This is a speculative "we might be able to improve things" bug that is light on
> specifics. There is one blocking bug that is also light on specifics.
>
> I suggest P2.

I did P2. jrmuizel added some very helpful new information from the
Chrome team: https://bugzilla.mozilla.org/show_bug.cgi?id=1190409#c3

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1190719
> * High power usage on 8tracks.com
>
> On Mac, for this music-playing site rapl says Firefox uses ~22.7 Watts, Safari
> uses ~7.1 and Chrome uses ~5.8. Animation of a progress bar might be a factor.
>
> I suggest P2, because it's not a widely-used site.

I did P2.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1190721
> * High power usage on businessinsider.com
>
> On Mac we are slightly worse than Safari (rapl says ~4.1 Watts vs ~3.5 Watts).
> An off-screen transform animation seems to be a factor; blocking bug 1166500
> will hopefully fix that.
>
> I suggest P3 because the difference with Safari is small.

I did P3.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1190722
> * High power usage on BuzzFeed
>
> On Mac, we're much worse than Safari on the Buzzfeed front page: rapl says
> ~20.5 Watts vs. ~4.2 Watts. This is due to an invisible CSS animation that
> triggers excessive display list building. Bug 1166500 is about fixing that
> issue, and bbirtles is working on it.
>
> I suggest P2 because BuzzFeed is popular but not, for example, YouTube-level
> popular. (And I will suggest P1 for bug 1166500 when it comes up because it
> will help on other sites.)

I did P2.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1194049
> * NsdManager increases power consumption
>
> mfinkle found that NsdManager was the #3 power usage on his Nexus 5, using 6%.
> xeonchen and schien are working on patches. I needinfo'd xeonchen to ask what
> if there are any measurements with the patches applied.
>
> I tentatively suggest P1 because it sounds like something that might affect
> many Fennec users.

I did P1. All the patches have r+ so this looks close to landing.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1195790
> * YouTube uses a lot more power in FF than Safari on OS X
>
> On Mac, rapl says the following while playing a YouTube video: Firefox uses
> ~12.6 Watts, Safari uses ~7.5 Watts, and Chrome uses 11.9 Watts. (After those
> measurements were made, bug 1195767 landed which reduced Firefox's usage by
> ~0.6 Watts.)
>
> I suggest P1 because YouTube is so important. We should also see how we do on
> YouTube on Windows and Android, though measurements are harder on those
> platforms, esp. Android. If anyone can take those measurements on appropriate
> hardware (i.e. not in a VM) and file bugs, that would be great. On Windows, I
> suggest using Intel Power Gadget; on Android I'm not sure what the best way to
> measure power consumption is.

I did P1.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1197902
> * Reduce the number of CCTimerFired wakeups
>
> CCTimerFired wakeups happen up to four times per second, per process. It's not
> a large number but it's something that's present across many workloads. mccr8
> has ideas to reduce it, and a draft patch.
>
> I suggest P2.

I did P2.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1200028
> * High CPU usage on a fujitsu-general.com page
>
> On Windows, two people saw 100% CPU usage on this page on Windows. On Mac, rapl
> says ~14.3 Watts processor+memory power usage compared with ~3.5 Watts for
> Safari and ~4.3 Watts for Chrome.
>
> So we're doing quite badly compared to other browsers but it's not a
> high-exposure page. I suggest P2. See also bug 1203766 below, which has a
> partial fix.

I did P2.

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1203427
> * Add logging for timer firings
>
> This bug has patches, awaiting review, that add logging to every timer firing.
> The patches print the timer callback function. Timer firings trigger wakeups
> and are a common cause of high power consumption. In the past both azakai and
> rvitillo have found this kind of profiling to be effective, and the patches
> build on their prior efforts.
>
> I suggest P1, because this will likely get significant usage.

I did P1, and this has landed. Docs are here:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/TimerFirings_logging

> * https://bugzilla.mozilla.org/show_bug.cgi?id=1203766
> * cache style contexts resolved by nsComputedDOMStyle for display:none elements
>
> This bug has patches from heycam that avoid a lot of style context resolution
> when looking at computed style objects for display:none elements, by using
> caching. The patches mostly have r+ but need a few fix-ups. This reduces the
> power consumption on Mac of the Fujitsu page mentioned above from ~14.6 Watts
> to ~8 Watts, according to rapl.
>
> This is a good result, but it's not clear if this fix will have wide
> applicability. Therefore I suggest P2.

I did P2, and this has landed.

[Kartikaya Gupta]

FWIW I did read through your original triage email, and looked at a
couple of the interesting-sounding bugs. I didn't disagree with your
prioritization on any of them. I do also really like this format for
triaging *much* better than the "let's all sit around on Vidyo" method
that usually happens at Mozilla. I would very much like to see this
adopted by more teams!

Cheers,
kats

On Thu, Sep 17, 2015 at 8:03 PM, Nicholas Nethercote

> _______________________________________________
> dev-power mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-power

[Josh Matthews]

Same here on all counts.

Cheers,
Josh

[Ehsan Akhgari]

Same here as well.

Although, I also understand where you're coming from, since it's often
difficult to figure out if silence means "nobody cares" or "all agree".
I would be happy to respond with a +1 the next time if that helps
clarify, and we can invite others to do the same.

Cheers,
Ehsan

On 2015-09-18 8:05 AM, Josh Matthews wrote:
> Same here on all counts.
>
> Cheers,
> Josh
>
> On 2015-09-17 11:49 PM, Kartikaya Gupta wrote:

[Mark Finkle]

+1

On Fri, Sep 18, 2015 at 10:02 AM, Ehsan Akhgari <ehsan....@gmail.com> wrote:

Same here as well.

Although, I also understand where you're coming from, since it's often difficult to figure out if silence means "nobody cares" or "all agree".  I would be happy to respond with a +1 the next time if that helps clarify, and we can invite others to do the same.

Cheers,
Ehsan

On 2015-09-18 8:05 AM, Josh Matthews wrote:

Same here on all counts.

Cheers,
Josh

On 2015-09-17 11:49 PM, Kartikaya Gupta wrote:

[Nathan Froyd]

On Mon, Sep 14, 2015 at 12:31 AM, Nicholas Nethercote <n.neth...@gmail.com> wrote:

* https://bugzilla.mozilla.org/show_bug.cgi?id=1190722
* High power usage on BuzzFeed

On Mac, we're much worse than Safari on the Buzzfeed front page: rapl says
~20.5 Watts vs. ~4.2 Watts. This is due to an invisible CSS animation that
triggers excessive display list building. Bug 1166500 is about fixing that
issue, and bbirtles is working on it.

I suggest P2 because BuzzFeed is popular but not, for example, YouTube-level
popular. (And I will suggest P1 for bug 1166500 when it comes up because it
will help on other sites.)

This is the only one I would have suggested a different rating for (P1).  Granted, BuzzFeed is not YouTube, but it's still a top 40 site for the US.

P2 would be OK if we knew that most of the difference would be erased by bug 1166500; it wasn't clear to me that that bug will magically bring our power usage down by 70-80%.

-Nathan

[Birunthan Mohanathas]

On 17 September 2015 at 17:03, Nicholas Nethercote

<n.neth...@gmail.com> wrote:
> Hello again,
>
> There were no responses to the initial triage email, so I added
> priorities as I suggested earlier. Details are below.
>
> I'm not sure how to interpret the lack of response. I fear that this
> email-based process may be fatally compromised by Warnock's Dilemma
> (https://en.wikipedia.org/wiki/Warnock's_dilemma). But I will continue
> trying it for at least a few weeks more.

I'm not involved with this initiative, but I do find power consumption
an important issue. Your emails are a great way to keep track of the
state of things. I really appreciate this format. Thank you for
choosing email!

Cheers,
Biru

[Nicholas Nethercote]

Thank you to all those who replied. It's reassuring :)

> I would be happy to respond with a +1 the next time if that helps clarify, and
> we can invite others to do the same.

That would be helpful! I will put that suggestion in the preamble for
the next triage thread.

Nick

[Nicholas Nethercote]

On Sat, Sep 19, 2015 at 12:12 AM, Nathan Froyd <nfr...@mozilla.com> wrote:
>
> This is the only one I would have suggested a different rating for (P1).
> Granted, BuzzFeed is not YouTube, but it's still a top 40 site for the US.

I didn't realize it was that popular. I've upgraded to P1. Thank you
for the suggestion.

Nick