ARMBrowserPerformance

Summary

This session is about presenting the current state of performance in web browsers on ARM, and then deciding on how to implement benchmarking/validation for browsers so that performance can be quantified and tracked.

Release Note

No user visible changes.

Rationale

Browser performance is of increasing importance due to more and more applications moving to the browser. For example, we now have an office suite packaged for Ubuntu that uses Zoho in a browser instead of a heavier client-side application. The emphasis on browser performance is especially true on ARM devices where memory and cache are often more limited, and since ARM processors are often targeted at consumer devices such as netbooks and phones.

Assumptions

The browser works and is capable of running javascript.

Design

There are three major areas that should be measured and addressed for performance benchmarks:

  • Browser load time
  • Javascript Performance
  • Page load performance

Implementation

For browser load time, the cache should be cleared, then a script can launch the browser and measure the time it takes for the browser to come up. LDTP is one option for scripting and measuring this. Another option that was suggested is having it load a page with a simple javascript to change the title of the page to the timestamp. These timestamp could then be grabbed from the window title.

For Javascript performance, there are quite a few browser benchmarks currently available. Many of these have already been consolidated in the dromaeo testsuite. A wrapper will need to be written to allow for automation of running the tests and gathering the results once the tests are completed.

For page load performance, a javascript wrapper can be placed around a page to determine how long it takes to load. Similar automation as mentioned above will need to handle automating the browser bringup and gathering of results. Commonly used pages will need to either be simulated, or modified to run locally (respecting any potential copyrights).

BoF agenda and discussion

Blueprint: https://blueprints.launchpad.net/ubuntu-arm/+spec/arm-m-webkit-and-browser-performance

Chromium performance:
 * Networking
 * HTML
 * Javascript

PGO optimized gcc development environment.
 * Needs toolchain development / investigation to get -freorder-blocks-and-partition to work.
 * need to test with something like microbenchmarks to see how much improvement we could expect
 * One of the Mozilla blogs for PGO - http://blog.mozilla.com/tglek/2010/04/12/squeezing-every-last-bit-of-performance-out-of-the-linux-toolchain/
 
 main two things are rendering and js performance
 
Benchmarks
 * dromaeo.com (mozilla) - mixture of js and html rendering perf
 * v8 benchmark (google) - pure javascript perf
 * sun spider (apple) - also pure javascript perf
 * pagecycler - measures page load performance (parse and render) 
   - requires a special binary, and modification of test pages
   - http://build.chromium.org/buildbot/perf/xp-release-dual-core/moz/report.html?history=150&rev=-1
   - page copyrights are a real problem, since you can't redistribute a page
 * http://www.eembc.org/home.php - may be working on a browser benchmark
 * webkit wiki page collecting benchmarks - http://trac.webkit.org/wiki/JavaScript%20and%20DOM%20Benchmarks
 * startup time of browsers using window title maybe to extract that info.
 * multimedia benchmarks: html5 video, canvas etc.
   - video codecs are a large part, so benchmarking gstreamer itself might cover it
   - hardware vendors often develop codecs themselves for their particular hardware (as a gstreamer plugin)
   - browsers:
     - mozilla uses ffmpeg, working on gstreamer
     - chromium uses ffmpeg
     - webkitgtk uses gstreamer (i think) <- yes, it does
   - ffmpeg has an "arm" directory filled with assembly: http://src.chromium.org/viewvc/chrome/trunk/deps/third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/arm/
 * flash
   - arm build, but not public

CategorySpec

Specs/M/ARMBrowserPerformance (last edited 2010-05-28 01:48:45 by 216)