Announcing the Gecko Profiler

[Benoit Girard]

We're happy to announce that the 'Gecko Profiler' is ready for broad usage.
This is a cross-platform profiler (win, mac, linux, fennec) for platform
code (C/C++) that is easy to setup, lets you focus your view on 'jank'
events, can be kept always-on to provide something like Shark's WTF Mode,
exports small profiles for attachment/linking to bugzilla.

With this profiler you'll be able to ask users to submit a performance
profile by following a few simple steps that takes approximately 10 minutes
and does not require building firefox or setting up PDBs/symbols:
https://developer.mozilla.org/en/Performance/Reporting_a_Performance_Problem

By switching from nightly to the profiling-nightly channel power-users will
be able browse the web with low overhead profiling enabled, catch short
jank and report them. For instruction how to set this up see:
https://developer.mozilla.org/en/Performance/Profiling_with_the_Built-in_Profiler#Running_the_profiler

For more detailed technical explanation see:
https://developer.mozilla.org/en/Performance/Profiling_with_the_Built-in_Profiler
http://benoitgirard.wordpress.com/2012/03/30/writing-a-profiler/

You can see our known issue and feature requests here:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=component%3Agecko;list_id=3226726

Here's a sample profile collected while writing this email in gmail:
http://people.mozilla.com/~bgirard/cleopatra/?report=AMIfv95DnNDRY9gdUBtTt0adpr0-zQLHOanXop-5TlO0IbzwsukXjV28HmReUwETPO54cC0-xPj-7wuoLujcn-bY_bt1KT_tYRA6QMilvnQeqbtxTWT4pk26Xlr8t5si2f-sFlVLmHl3SYV6J5TgKBRj5EhFHQPT6w

Please file bugs and feature requests to 'Core::Gecko Profiler'.

Our next priorities with this tool is:
(1) Profiling multiple threads (bug
734691<https://bugzilla.mozilla.org/show_bug.cgi?id=734691>
)
(2) JS Integration (Bug
736299<https://bugzilla.mozilla.org/show_bug.cgi?id=736299>
)
(3) Automated profile collection for certain performance test suites
(4) UI improvements

Here's a preemptive Q&A:

Q: Why write a new profiler instead of using VTune, Instruments or X?

A: While the feature set of the Gecko Profiler and some specific profiler
does overlap the Gecko Profiler provides features not covered by other
profilers. It integrates with our event loop responsiveness and can
correlate samples with jank, it doesn't require a custom build, it doesn't
require large PDBs to profile, the profiles can be exported to others, it
works across platform, on android it doesn't require an unlock phone etc...
Likewise it doesn't provide all the functionality of some popular profilers
so you will likely still want to use them.

- Benoit Girard

[Alex Keybl]

This will get a lot of mileage out of perf bugs tracked for release. Is there a reference I can look at to understand what performance regression scenarios the Gecko Profiler would not be helpful in diagnosing? Based upon the remaining work, it seems as if JS-related issues may be better profiled in the future. Thanks in advance.

-Alex

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

[Benoit Girard]

That's an excellent question. So far we've identified 2 cases where the
profiler doesn't work well. The first is a real problem when hunting for
regression, the second is likely to cause some false report to be filled.

When JS is causing the performance problem. For example I have been seeing
a lot of synchronous DOM Storage jank events caught by the profiler during
my daily browsing. In that case we see main thread IO in 'read/write'
functions but we can't find which script is causing the main thread IO.
Worse is if JS JIT is causing the hang directly there will be less
information to find the script. We're hoping to address these JS
integration.

When the problem is caused by resource starvation such as swapping and IO
starvation functions like 'memmove' and 'read' will collect many samples.
Currently we can't differentiate between doing a large operation or doing a
small operation during system contention. We're hoping to address this by
collecting system level performance information. In this case you'll likely
want to use a profiler that already has this support such as Instruments on
Mac.

[Omega X]

Its very "Mac" like. But I'm not complaining. The more tools to track
down issues, the better.

--
==================================
~Omega X
MozillaZine Nightly Tester

[Alex Keybl]

> In that case we see main thread IO in 'read/write' functions but we can't find which script is causing the main thread IO.

It sounds like we'll at least know that JS is the culprit in these instances, which will be a good start regardless. Thanks for the background!

-Alex

On May 29, 2012, at 10:16 AM, Benoit Girard wrote:

> That's an excellent question. So far we've identified 2 cases where the profiler doesn't work well. The first is a real problem when hunting for regression, the second is likely to cause some false report to be filled.
>
> When JS is causing the performance problem. For example I have been seeing a lot of synchronous DOM Storage jank events caught by the profiler during my daily browsing. In that case we see main thread IO in 'read/write' functions but we can't find which script is causing the main thread IO. Worse is if JS JIT is causing the hang directly there will be less information to find the script. We're hoping to address these JS integration.
>
> When the problem is caused by resource starvation such as swapping and IO starvation functions like 'memmove' and 'read' will collect many samples. Currently we can't differentiate between doing a large operation or doing a small operation during system contention. We're hoping to address this by collecting system level performance information. In this case you'll likely want to use a profiler that already has this support such as Instruments on Mac.
>
> On Tue, May 29, 2012 at 12:59 PM, Alex Keybl <ake...@mozilla.com> wrote:
> This will get a lot of mileage out of perf bugs tracked for release. Is there a reference I can look at to understand what performance regression scenarios the Gecko Profiler would not be helpful in diagnosing? Based upon the remaining work, it seems as if JS-related issues may be better profiled in the future. Thanks in advance.
>
> -Alex
>

[Neil]

Benoit Girard wrote:

>We're happy to announce that the 'Gecko Profiler' is ready for broad usage.
>

Well, usage on Firefox; at least, I don't see any instructions relevant
for other Gecko applications...

--
Warning: May contain traces of nuts.

[Benoit Girard]

Here's a profile to illustrate an example. JS is getting blamed but we
don't yet have a way to find which script is causing the problem.

Test page (Click on 'Block the main thread'):
http://people.mozilla.org/~bgirard/Video.html

JS Snipplet (Blocks the main thread for 500ms repeatably):
function blockMe() {
var blockStart = new Date().getTime();
while(blockStart + 500 > new Date().getTime()) {}
setTimeout(blockMe, 0);
}

Profile:
http://people.mozilla.com/~bgirard/cleopatra/?report=AMIfv96iIajbBcvO66Ls2dAIXm0o6tztl81yDA5t6nPOPypGydJcVewVlEfUz_pzDn4uzYNMYm3ahy3_4yChVZfJc7mQkZHtJJuKMfoVgRb8hZkhmulkwQSSiiysOpxFEDTHTRpnnfpOchYybgxWmUptj5L9KJjDoQ

> > On May 29, 2012, at 9:55 AM, Benoit Girard wrote:
> >
> > > We're happy to announce that the 'Gecko Profiler' is ready for broad
> usage.

[Benoit Girard]

I have reached out to Thunderbird and B2G. Both should require only minimal
efforts to port the UI of the extension:
https://bugzilla.mozilla.org/show_bug.cgi?id=740946
https://bugzilla.mozilla.org/show_bug.cgi?id=758697 (This was discussed
more on IRC)

> ______________________________**_________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/**listinfo/dev-platform<https://lists.mozilla.org/listinfo/dev-platform>
>

[Gervase Markham]

I'll switch to the profiling channel.

On 29/05/12 17:55, Benoit Girard wrote:
> Here's a sample profile collected while writing this email in gmail:
> http://people.mozilla.com/~bgirard/cleopatra/?report=AMIfv95DnNDRY9gdUBtTt0adpr0-zQLHOanXop-5TlO0IbzwsukXjV28HmReUwETPO54cC0-xPj-7wuoLujcn-bY_bt1KT_tYRA6QMilvnQeqbtxTWT4pk26Xlr8t5si2f-sFlVLmHl3SYV6J5TgKBRj5EhFHQPT6w

Cleopatra is an awesome name for a profile-related piece of software.
Kudos :-) Now all you need to do is rename "SPS" to "aSPS"...

Gerv

[Ehsan Akhgari]

The credit for the name goes to Josh. :-) I remember when I first
created the repository we were looking for a name, and Cleopatra was
suggested by Josh (for reasons which I've since forgotten).

--
Ehsan
<http://ehsanakhgari.org/>

[Gervase Markham]

On 01/06/12 00:24, Ehsan Akhgari wrote:
> The credit for the name goes to Josh. :-) I remember when I first
> created the repository we were looking for a name, and Cleopatra was
> suggested by Josh (for reasons which I've since forgotten).

Wikipedia sayeth:

In his Pensées, philosopher Blaise Pascal contends, evidently
speaking ironically because a large nose has symbolized dominance in
different periods of history, that Cleopatra's classically beautiful
profile changed world history: "Cleopatra's nose, had it been
shorter, the whole face of the world would have been changed."

As you can see, she had a significant conk:
http://en.wikipedia.org/wiki/File:Kleopatra-VII.-Altes-Museum-Berlin1.jpg

Gerv