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
<ehsan.akhg...@gmail.com <mailto:ehsan.akhg...@gmail.com>> 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
    <https://bugzilla.mozilla.org/show_bug.cgi?id=1346415> 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/
    <https://people-mozilla.org/%7Emlayzell/bhr/>. For example, this
    <https://people-mozilla.org/%7Emlayzell/bhr/20170405.html> 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
    <https://bugzilla.mozilla.org/show_bug.cgi?id=1344003> 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 <https://mikeconley.github.io/ohnoreflow/>.  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

<https://bugzilla.mozilla.org/buglist.cgi?quicksearch=sw%3A%22%5Bohnoreflow%5D%22&list_id=13547427>

    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
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1352442>. This
        made some painting and scrolling related benchmarks faster
        <https://treeherder.mozilla.org/perf.html#/alerts?id=5801>,
        and fixed a flickering issue
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1330814> in the
        mean time!
      * Mason Chang made the Youtube settings widget less janky
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1351733> 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
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1307134>.
      * Neil Deakin removed a synchronous layout flush
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1334635> 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
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1345315> which
        could slow down tab animations (yes!).  Dão also removed a
        synchronous layout flush
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1356655> which
        could slow down detaching a tab into a new window and he also
        lazified some code to avoid some more layout flushes
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1356663> which
        were related to the status panel.
      * Markus Stange made the Gecko Profiler not kill your battery
        after you stop profiling
        <https://bugzilla.mozilla.org/show_bug.cgi?id=830990>, and
        also made it so that once you start profiling a thread, you
        can actually stop profiling it
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1346592>.
      * Michael Layzell excluded some common file JS file extensions
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1352684> from
        the expensive computation that we run on Windows to determine
        the mimetype of a file from its extension.
      * Kris Maglione made it possible to load add-on SDK modules
        lazily <https://bugzilla.mozilla.org/show_bug.cgi?id=1314861>.
        He also made loading ExtensionContent.jsm lazy
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1317697>. These
        two changes together (but probably mostly the former) showed
        great improvements on Talos
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1314861#c52>.
        This is even true for users without any add-ons using the
        add-on SDK since these modules are also used in our internal
code.
      * Robert Helmer created a Go Faster add-on
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1356676> to
        quickly deploy the fix of bug 1353216
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1353216> to
        Firefox 52 users even before they upgrade to Firefox 53 which
        includes the fix!
      * Edouard Oger made Firefox Sync UI code cache the
        DateTimeFormat objects
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1350613> where
        possible.
      * Alastor Wu made some Fennec media controls code that could be
        expensive not run on Firefox desktop
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1348803>.
      * Makoto Kato added a cache for document encoder objects used by
        TextEditor
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1352882>, in
        order to improve the performance of setting the value of
        HTMLInputElement.value.
      * Tom Schuster optimized Object.hasOwnProperty()
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1344469>. This
        is a commonly used JavaScript built-in on real web pages,
        really nice optimization to have!
      * Florian Quèze removed a synchronous layout flush
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1353563> that
        used to happen when displaying each item in the awesome bar.
        He improved the awesomebar even more by caching the one-off
        search buttons instead of regenerating them every time we open
        the popup
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1312999>.
        Furthermore, he ensured that we don't pay the cost of
        initializing UITour.jsm for pages that do not display a UI
        tour <https://bugzilla.mozilla.org/show_bug.cgi?id=1349742>.
      * Wei-Cheng Pan added telemetry probes for navigation timings
        and time to first byte measures
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1344893>.
      * Shu-yu Guo improved the timing of script source compression by
        delaying it until GC
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1348134>.
        Previously we used to do this when parsing JavaScript (on a
        separate thread) which is wasteful because it would mean that
        we'd have to decompress the compressed source during page load
        sometimes, and also burning needless CPU cycles during JS
        parsing isn't wise.
      * J. Ryan Stinnett made the Developer Toolbar not create a
        network listener for every single tab that you have open
        <https://bugzilla.mozilla.org/show_bug.cgi?id=1346854>.
        Besides perf wins, this means fewer OOM crashes too!

    Thanks for reading!  Until next time, happy hacking!

    --     Ehsan

    _______________________________________________
    firefox-dev mailing list
    firefox-...@mozilla.org <mailto:firefox-...@mozilla.org>
    https://mail.mozilla.org/listinfo/firefox-dev
    <https://mail.mozilla.org/listinfo/firefox-dev>




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

Reply via email to