Home · All Namespaces · All Classes · Grouped Classes · Modules · Functions codeless banner

Identifying Performance Issues

Introduction

This document details processes which can be used to identify performance issues.

Performance Test Results

The Qt Extended documentation includes performance test results for released versions of Qt Extended on several devices. This data may help establish performance expectations for Qt Extended.

Valgrind

Valgrind is a tool which profiles applications by running code under a simulated x86 CPU. Valgrind outputs highly detailed information which can be helpful in identifying performance issues.

Valgrind cannot be used on non-x86 embedded devices.

Process

The process for using valgrind is as follows:

  1. Build Qt Extended and Qt/E for desktop in release mode adding the options -g and -O2 to the specification file for RELEASE. The specification file(s) to modify depend on the release of Qt Extended being used, that is:
  2. Qtopia / Qt Extended Version 4.x modify qmake.conf
  3. Run using:
        bin/runqtopia -qpe bin/worldtime -runmode callgrind -- --dump-every-bb=500000
  4. To profile all applications:
        bin/runqtopia -runmode callgrind -- --trace-children=yes
  5. Ctrl-C to exit the application after startup
  6. kcachegrind &

Checking Memory Usage

valgrind can provide valuable information as follows:

Things to Note

  1. Ensure View->Cycle Detection is off otherwise data will not display correctly.
  2. When determining performance measures use the following as a guide:

    Note: How was the estimate of 10M instructions/sec was determined?

  3. it is known from callgrind that 60M instructions are executed on startup.
  4. it is known that the time taken to start was 6 seconds.

Therefore, 60M / 6s = 10M instructions/second.

It is difficult to obtain accurate values as other factors effect results so when measuring startup times on device, repeat it a number of times and take the average value.

Timestamped Logs

Qt Extended contains many logs which can be enabled or disabled at runtime. Timestamps can be enabled on these log messages to help determine where time is being spent.

Process

Enable timestamps by modifying the Log2.conf log settings file. This process is documented here. A format string should be set which contains the %t specifier for timestamps. For example, write the following to $HOME/Settings/Trolltech/Log2.conf :

    [MessageHandler]
    Format = %t %p %n: %s

Enable any qLog categories relevant to the code of interest.

Results

Using the above log format results in log messages like the following:

    ...
    606 2563 qpe: Input :  Loading IM:  "qdockedkeyboard"
    611 2569 mediaserver: begin timestamped log messages
    613 2563 qpe: Input :  DockedKeyboard Instatiated.
    613 2563 qpe: Input :  Docking input widget for  "DockedKeyboard"
    614 2563 qpe: Input :  Loading IM:  "qkeyboard"
    618 2563 qpe: Input :  Loading IM:  "qpredictivekeyboard"
    625 2563 qpe: Input :  Docking input widget for  "PredictiveKeyboard"
    ...
    735 2563 qpe: Component :  Creating callScreen
    735 2563 qpe: QtopiaServer :  Server widget mapping:  "CallScreen" -> "Themed"
    739 2563 qpe: Component :  Created callScreen
    ...

The timestamp at the beginning of each log message can be used to determine how much time certain tasks take, while the PID (process identifier) and process name allow log messages from separate processes to be separated. In the above example it can be seen that loading the "qpredictivekeyboard" input method takes 7 milliseconds and creating the call screen takes 4 milliseconds.


Copyright © 2009 Trolltech Trademarks
Qt Extended 4.4.3