I didn’t get a chance to write up a performance check-up post at the end of September, so this entry reviews September and October.
- New Talos tcanvasmark test added in September
- Talos tsvgx replaced the previous SVG test
- Talos Tp4m and Ts tests updated
- New “responsiveness” measures added to Eideticker tests
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 newly added (September 2013) 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.
High variability and regressions in August/September — see bug 913683.
15 (Sept 1) – 30 (Oct 30)
Panning performance test. Value is square of frame delays (ms greater than 25 ms) encountered while panning. Lower values are better.
16000000 (Sept 1) – 140000 (Oct 30)
The very significant regression from August (bug 908823) was fixed in September.
A closer look at October reveals another, smaller, regression.
Regression of October 23 – see bug 877203.
Performance of history and bookmarks’ provider. Reports time (ms) to perform a group of database operations. Lower values are better.
375 (Sept 1) – 375 (Oct 30).
This test was introduced in September, replacing the previous SVG test (see Replacing tscroll,tsvg with tscrollx,tsvgx).
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.
1200 (Sept 19) – 1350 (Oct 30)
Regression of Oct 17 – see bug 923193.
This test was updated in September, replacing tp4m_nochrome.
Generic page load test. Lower values are better.
700 (Sept 19) – 700 (Oct 30).
136000000 (Sept 19) – 136000000 ( Oct 30).
Another test updated in September.
Startup performance test. Lower values are better.
4300 (Sept 19) – 4300 (Oct 30).
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.
Time to throbber start was pretty stable during this period.
“Time to throbber stop” measures the time from process launch to the end of the throbber animation. Smaller values are better.
Time to throbber stop was pretty stable during this period.
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
Eideticker now includes a “responsiveness” measure for several of the existing tests. See http://wrla.ch/blog/2013/10/first-eideticker-responsiveness-tests/ for background information.
Most of the other measures seem fairly stable for September/October. Here are some of the more active graphs:
See https://www.areweslimyet.com/mobile/ for content and background information.