The Chromium Projects

Search this site

Except as otherwise noted, the content of this page is licensed under a Creative Commons Attribution 2.5 license, and examples are licensed under the BSD License.

Recording Tracing Runs

What it does
When diagnosing performance problems it can be valuable to see what Chrome is doing "under the hood." One way to get a more detailed view into what's going on is to use the about:tracing tool.

See Trace Event Profiling Tool (about:tracing) for more information on what this tool does.

How to record tracing runs (desktop)

Sometimes Chromium developers will ask for about:tracing results in a bug report to help us understand what's going on. Recording a tracing run is easy:
    1. Open up a new tab and type "about:tracing" in the Omnibox
    2. Hit "record"
    3. Switch back to the tab with the content you're debugging and do whatever it is that's slower than it should be (or behaving incorrectly). A few seconds of the bad activity is usually sufficient.
    4. Switch back to the tracing tab and hit "Stop tracing", then hit "Save"
    5. (Optional) If this is for a bug report, upload the output file as an attachment to bug. If the file is bigger than 10MB, zip it first (the files compress well, and files bigger than 10MB can be truncated during upload).
You can also record traces when starting chrome. Assuming $CHROME is set to the command you need on your OS to start chrome, the following will record the first 7 seconds of Chrome's lifetime into /tmp/foo.json
$CHROME --trace-startup --trace-startup-file=/tmp/foo.json  --trace-startup-duration=7


How to record tracing runs (Chrome on Android)

You can even record tracing runs from Chrome on Android, though it's a bit more involved. You'll need your device running Chrome on Android with USB debugging enabled and attached to your computer. You'll also need ADB. With these prerequisites in place, you can choose from the following two methods to record traces:

Method 1:

Run the script https://github.com/johnmccutchan/adb_trace to get the trace. Thanks John Mccutchan for writing it.

Or issue the following ADB command from your computer's shell:

$ adb shell am broadcast -a com.android.chrome.GPU_PROFILER_START -e file /sdcard/Download/trace.txt
(Note: 'com.android.chrome' is the package name for Chrome Stable. See below Note for Chrome Beta and other versions if you are tracing Chrome Beta or other versions)
  
Now do whatever is slow or incorrect in the browser on the device, then issue:

$ adb shell am broadcast -a com.android.chrome.GPU_PROFILER_STOP
(Also note the package name)

The results of the tracing run will be stored in /sdcard/Download. You can pull the file off of device and onto your computer with:

$ adb pull /sdcard/Download/trace.txt /path/on/your/computer/trace.txt

And access the trace file locally at /path/on/your/computer/trace.txt

Note for Chrome Beta and other versions: For the above commands to work you'll need to change the package name to whatever is appropriate for the APK. For instance, for Chrome for Android Beta change "com.android.chrome.GPU_PROFILER_START" to "com.chrome.beta.GPU_PROFILER_START" and so on (i.e. sub com.chrome.beta for com.android.chrome everywhere). For ContentShell, the commands are "org.chromium.content_shell.action.PROFILE_START" and "org.chromium.content_shell.action.PROFILE_START".

Method 2:

You can also use Android systrace to get trace if you are using Android JellyBean.

Pros: 1. It can show other Android system traces (e.g. surfaceflinger though some require root) along with Chrome traces; 2. It generates a self-contained html file.
Cons: It lacks some Chrome trace features, e.g. asynchronous events.

See http://developer.android.com/tools/help/systrace.html for the usage of systrace. Use 'view' category to enable Chrome trace.

Making a Good Recording
  • Keep the recording to a max of 10 seconds
  • Try to keep to 1 activity per recording. If you see two slowdowns, do one recording each. Or leave a second long pause between each.
  • Pause and leave the computer completely idle for 2 seconds before and after demonstrating the slowdown. This helps make the slow part obvious in the recording.
Step by step:

  1. Start with only the tab you’re investigating and about:tracing open in a fresh browser session (see below for other methods of figuring out which tab is which if you need multiple).
  2. Set up the tab for investigation to right before the point where the problem will occur (e.g. right before an animation is going to be triggered, or right before part of the page that scrolls slowly)
  3. Start a tracing run in the about:tracing tab
  4. Switch to the tab under investigation
  5. Pause for a couple seconds to record empty space on the timeline (makes finding it later easier)
  6. Perform the action to trigger the bad performance behavior (e.g. start the animation or scroll the page). Keeping the recorded activity under 10 seconds is a good idea.
  7. Pause again
  8. Switch back to the about:tracing tab and stop the recording.
Comments