, ,

My monthly review of Firefox for Android performance measurements.

January highlights:

– only minor Talos regressions

– Eideticker startup regressions

– inconsistent improvement in many awsy measures


This section tracks Perfomatic graphs from graphs.mozilla.org for mozilla-central builds of Native Fennec (Android 2.2 opt). The test names shown are those used on tbpl. See https://wiki.mozilla.org/Buildbot/Talos for background on Talos.


This test runs the third-party CanvasMark benchmark suite, which measures the browser’s ability to render a variety of canvas animations at a smooth framerate as the scenes grow more complex. Results are a score “based on the length of time the browser was able to maintain the test scene at greater than 30 FPS, multiplied by a weighting for the complexity of each test type”. Higher values are better.

7800 (start of period) – 7800 (end of period).


Measure of “checkerboarding” during simulation of real user interaction with page. Lower values are better.


2.5 (start of period) – 2.7 (end of period)

Jan 16 regression – bug 961869.


Panning performance test. Value is square of frame delays (ms greater than 25 ms) encountered while panning. Lower values are better.

110000 (start of period) – 110000 (end of period)


Performance of history and bookmarks’ provider. Reports time (ms) to perform a group of database operations. Lower values are better.

375 (start of period) – 375 (end of period).


An svg-only number that measures SVG rendering performance. About half of the tests are animations or iterations of rendering. This ASAP test (tsvgx) iterates in unlimited frame-rate mode thus reflecting the maximum rendering throughput of each test. The reported value is the page load time, or, for animations/iterations – overall duration the sequence/animation took to complete. Lower values are better.


7200 (start of period) – 7500 (end of period).

Regression of Jan 7 – bug 958129.


Generic page load test. Lower values are better.

700 (start of period) – 700 (end of period).


Startup performance test. Lower values are better.

4300 (start of period) – 4300 (end of period).

Throbber Start / Throbber Stop

These graphs are taken from http://phonedash.mozilla.org.  Browser startup performance is measured on real phones (a variety of popular devices).

“Time to throbber start” measures the time from process launch to the start of the throbber animation. Smaller values are better.


There is so much data here, it is hard to see what is happening – bug 967052. I filtered out many of the devices to get this:


I think existing, long-running devices are showing no regressions, and some of the new devices are exhibiting a lot of noise — a problem that :bc is working to correct.

“Time to throbber stop” measures the time from process launch to the end of the throbber animation. Smaller values are better.


A similar story here, I think.

But there was a regression for some devices on Jan 24 – bug 964323.


These graphs are taken from http://eideticker.mozilla.org. Eideticker is a performance harness that measures user perceived performance of web browsers by video capturing them in action and subsequently running image analysis on the raw result.

More info at: https://wiki.mozilla.org/Project_Eideticker

Let’s look at our startup numbers this month:

eide1 eide2 eide3 eide4 eide5 eide6 eide7 eide8

Regressions noted in bugs 964307 and 966580.


See https://www.areweslimyet.com/mobile/ for content and background information.




There seems to be an improvement in several of the measurements, but it is inconsistent — it varies from one test run to the next. I wonder what that’s about.