Tuesday, January 13, 2009

Carbide.c++ Performance Investigator

The primary goal of the Carbide.c++ Performance Investigator (PI) is to gather performance data on a handheld device and save the data to a profiler data (.dat) file. On your PC workstation, PI lets you analyze that performance data. The Performance Investigator analyzer software is a plug-in to Eclipse Carbide.c++.

Importing the profiler data file in Carbide.c++ will launch the analyzer and present graphs and tables related to the data captured on the handheld target device.

The Performance Investigator collects performance data. It interrupts software execution at regular intervals and copies to memory the contents of some processor registers and the results of some Symbian OS calls.

The Performance Investigator contains two main parts:

First, on the target device is a user application called the Profiler. Installed with the Profiler is a device driver component that collects information from low-level (kernel and hardware-level) sources that are not generally accessed by application software. The Profiler acts as an interface to the device driver component and is required for its configuration, activation, and deactivation.

Second, on the PC there is Performance Investigator code integrated with Carbide.c++. This software consists of an importer for processing profiler data and the Analyzer, which provides a user-friendly way to examine and analyze the run-time performance information


Software Performance

Two fundamental goals in understanding software performance can be seen as:

The ability to know which part of the software the CPU is executing at any particular instance of time
The ability to know why the CPU is executing that particular software at that particular instance of time

Profiler

The profiler is the part of the Performance Investigator that resides on the target device. Its purpose is to gather performance measurement information from the device at run-time and to output the information to be analyzed within the Analyzer part of the tool. Each type of performance information recorded is called a trace. The most important Profiler traces include:

  • Address / thread trace periodically records the current program counter address and the currently executing thread.
  • Dynamic binary support trace periodically records information sufficient to determine which dynamically loaded user application or DLL is executing.
  • Function call trace periodically records the link register value, so that the caller of the currently executing routine can be determined.

Setting Tracing Options

Use the Tracing options menu in the Profiler to specify the types of tracing data to collect when profiling an application executing on a device.


Dynamic binary support
If the executables you wish to analyze are not in a ROM image (.symbol file) of your target device, then you will need to turn on Dynamic binary support.


Function call capture
If disabled, then Function call information will not appear in the Analyzer.

Button press capture
If disabled, then Button Press information will not appear in the Analyzer.

Memory usage capture
If disabled, then Memory usage information will not appear in the Analyzer.

Thread priority capture
If enabled, captured data will include the time and priority ranking of the currently executing thread when the operating system is called.
If disabled, then thread priority information is not included and a Priority List column will not be shown in the Thread Load table in the Analyzer.

Power usage capture
If disabled, then Power usage information will not appear in the Analyzer.

Trace Items

Recorded data is logically separated into different traces that can be selected or deselected by the Profiler. In analysis, trace data is combined with compile-time produced information (symbol files and binaries). All trace data and required symbolic information is stored in a stand-alone file that can be imported into the analyzer.

· Address/Thread Trace

This is a statistical trace for analyzing thread, binary, and function CPU load. All other traces are in synch with this trace, therefore, there has to be a address/thread trace in each measurement.
Address/Thread trace data can be visualized in different modes, depending on whether the items of interest are threads, binaries, or functions. For the elements associated with each mode, you can calculate the average CPU load within a selected time period, and display that information in tables and graphs. In all modes, address/thread trace graphs share the same semantics:

· Colors represent different trace items, such as threads, binaries, and functions
· Time is represented on the horizontal axis
· CPU load is represented on the vertical axis

· Button Press Trace

This provides an exact trace that records data about buttons pressed during the trace.
It is often useful to see the positions where different buttons were pressed during the trace. The mechanism for collecting BUP traces is simple. A key press event is then stored to the trace, along with the time the event took place

· Dynamic Binary Support Trace
During sampling, the dynamic binary support trace records the full path names, starting locations, and lengths of binaries loaded on the target device. That data is used to determine which binaries and functions are associated with address/thread trace samples taken in dynamic binaries.

· Function Call Trace
This is a statistical trace that records function caller/callee relationships during execution. The trace is based on periodically sampling link register values. With the link register value, it is possible to resolve the caller function for the currently executing function.
· Memory Trace

This trace takes samples of memory consumption of processes and threads. It records the free and total amount of memory on the device, the amount of memory allocated to kernel chunks, and the amount of memory allocated to stack/heap of each individual thread.

· Power Usage Trace

The Power Usage trace sampler uses a specific ISC channel to gather information about energy consumption from the Energy Management (EM) server running on the domestic OS. The sampler collects battery voltage, current, and capacity values, but it does not change any EM settings. The default sampling frequency is 4Hz (250ms), and the minimum allowed is 20Hz (50ms). Requesting an interval faster than the hardware supports will result in return values being identical to the previously sampled values.

· Thread Priority Trace

This trace takes samples of thread priorities. When the operating system is called, the time and priority ranking for the currently executing thread is recorded. Because a thread's priority may change over time, sometimes more than one priority ranking will be recorded for a thread.


Analyzer

The Performance Investigator Analyzer is used to graph, measure and analyze the collected traces from a device running the Profiler. It appears as a standard Analyzer view in a Carbide perspective.

The main analysis view is visible after trace data taken by the profiler has been imported into Carbide.c++ and opened with the Analyzer. The thread load data in the main analysis view is built from the address/thread trace. Other trace data is also shown in the main analysis view, such as dynamic binary support trace and function call trace. Figure 1 is an example view of imported profiler data that has been opened with the analyzer, including memory and power usage information, with a time interval of 9.1 to 13 seconds selected.

Analyzer main view showing Thread, Memory, and Power graphs
The address/thread trace graph is the most generic and perhaps most informative visual of the sampled data. The different colors represent different items. You can select Thread load, Binary load, or Function load as shown in Figure 2. Time is represented on the horizontal axis of the graph and share of CPU use is represented on the vertical axis

Selecting Threads, Binaries, Functions, or Function Calls

Each of the lines in the thread list represents a single thread. The color codes in the thread list correspond to the colors in the thread load graphs. Therefore, each color in the thread load graph represents the load of its corresponding thread.

You can select a portion of the graph by clicking on the trace graph. The Information view beneath the graph displays information about the currently selected part of the graph. For example, thread load statistics are shown in the information view if the thread load graph is selected.

Basic Analysis Procedure
The following gives basic guidelines how to proceed and find possible problems in the system during the actual analyzing work using the analyzer’s capabilities.

Overall CPU load graph

Scale the time line (i.e. x-axis) in the CPU load graph such that you can see all essential activity from start to end of the measurement. Display all threads. This gives an overview of overall CPU load during your use case.

NULL thread overview
Examine overall NULL thread execution. Time frames in which the NULL thread does not gain any CPU time are potential bottlenecks and need more detailed analysis. On the other hand, when the NULL thread has 100% of the CPU time, the system does not have anything to do. If this occurs, for example in the middle of intensive processing, available resources might be used non-optimally.

Overview of other threads
Find out thread(s) causing most of the CPU load. There are typically 1-3 high-load threads within the selected time frame. Study time frames that contain potential bottlenecks one by one.
Application characteristics overview

Take an overview of CPU load characteristics of the specific application(s) running in the use case. Focus on time frames in which the application(s) consume more CPU time than assumed. The binaries executing during those time frames tell you where time is being spent in user and system code.

Within the time frames requiring a more detailed analysis, try to determine at a high level what the application has been doing. When getting into a more detailed analysis, it is essential to know the origin causing the activity chain. For example, the end-user has completed a menu selection, which triggers playback of an audio file. The event has to be associated with a specific point in time in the CPU load profile.

Function-level analysis

Examine the set of functions called within high-load threads during selected time frames. Keep in mind that your use case will determine which threads are relevant to analysis. As a rule of thumb, threads consuming more than 10% of available CPU time are rational candidates to be analyzed.

When you analyze the binaries and functions in which the application spends most of its execution time, it is recommended that you analyze based on a single thread at a time.
For a high-load function, examine the code for an explanation (e.g., computation-intensive loop) as to why significant time was spent in the function. If you have captured function call data, examine the functions calling the high-load function to determine whether so many calls were necessary.

Friday, January 2, 2009

Beginning in Carbide C++

By visiting through different websites, I came to know that Carbide.c++ is the best IDE for the development of Symbian Applications. Carbide.c++ is a family of IDEs for the creation of C++ and C applications for Symbian OS devices. It is based on the Eclipse IDE and the C/C++ development tools from the Eclipse CDT Project.

Combining the power of the Eclipse Framework with tools for all stages of development, Carbide.c++ offers all Symbian C++, Qt, and Open C/C++ developers an efficient, easy-to-use development environment. And now Carbide.c++ is offered to every developer, from hobbyists to smartphone manufacturers, free of charge.
So I downloaded the latest version of Carbide.c++ i.e version 2.0 from the nokia forum website:
How do I get started with Carbide.c++?
To get started with Carbide.c++, you will need a PC with at least a 1.8-GHz processor, 2 GB of RAM, and 300 MB of free disk space (2 GB of free space will be needed if you don’t already have an SDK installed). The PC can be running Microsoft Windows XP or Windows Vista Business. You will also need ActiveState ActivePerl-5.6.1.635. For more information on the hardware and software requirements, see the release notes »

If you have this hardware, you can download and install Carbide.c++. The installation process is straightforward.

With Carbide.c++ installed, you might want to read the Carbide.c++: Introductory White Paper or view the Getting Started with Carbide.c++ Express Screencast, both of which will take you through the basics of creating, building, and deploying your first application.
Then consider reading the Carbide.c++ UI Designer White Paper to learn how UI Designer can help speed up development by creating application GUIs visually.

When your application is ready for testing, consider the On-Device Debugging with Carbide.c++ document or video. Both resources are designed to help you connect your device for on-device debugging and can guide you through the use of the debugging tools available in Carbide.c++.
Finally, the document Analyzing Application Performance with the Carbide.c++ Performance Investigator and the video Getting Started with Carbide.c++ Performance Investigator provide helpful information on capturing and analysing information on a device’s consumption of resources such as memory, CPU, and battery.
With which Symbian platforms and devices is Carbide.c++ compatible?
Carbide.c++ can be used to develop applications for S60 3rd Edition or later, UIQ 3.0 or later, and MOAP.
First I downloaded the latest SDK S60 5th edition from:
There is OpenC also available on S60 5.0 for S60 3.0
Uptill today, I have installed noth Carbide.c++ with S60 3rd Edition.
My next task is to read different tutorils relating to the beginning of Symbian programming using Carbide.c++.
I have downloaded different E-Books which can be found below. I have also found out that there are some Video tutorials related to the learning of Carbide.c++. I will share my experience relating to the Video tutorials later on.

Carbide.c++ can be used to develop applications for S60 3rd Edition or later, UIQ 3.0 or later, and MOAP.

E-Books
Using Symbian OS - Carbide.c++ v1.3
Carbide.c++ FAQ
S60 3rd Edition SDK for Symbian OS, Maintenance Release Installation Guide
Video Tutorials

Thursday, January 1, 2009

Introduction to Symbian SDKs

To begin developing applications for Symbian OS you will need a software development kit (SDK). SDKs for Symbian OS support development in both C++ and Java. [1]

They provide:

-binaries and tools to facilitate building and deployment of Symbian OS applications
-full system documentation for APIs and tools
-PC-based emulation of Symbian OS phones
-example applications with supporting documentation

SDKs are built based on a particular UI platform for Symbian OS. A UI platform provides a distinct UI and an associated set of system applications for such tasks as messaging, browsing, telephony, multimedia and contact/calendar management. These applications typically make use of generic application engines provided by Symbian OS. UI platforms intended to support the installation of third-party applications written in native C++ have to be supported by an SDK which defines that UI platform, or at least a particular version of it. Click the links to find more information on the SDKs for the following UI platforms: UIQ S60

The most important thing to know when developing an application for a particular phone is the associated UI platform. It is then important to find the Symbian OS version the phone is based on. You can then decide which SDK you need to obtain. In most cases, working with an SDK, you will be able to target a single version of your application at all phones based on the same UI platform and Symbian OS version.

UIQ
The following SDKs support development for phones based on the UIQ reference platform [2].
UIQ 2.1 SDK for Symbian OS
UIQ 2.0 SDK for Symbian OS

For further information on UIQ, visit the UIQ developer website.
www.developer.uiq.com

Phones based on UIQ 3.1 (Symbian OS v9.2)
Phones based on UIQ 3.0 (Symbian OS v9.1)

Phones based on UIQ 2.1 (Symbian OS v7.0)
Phones based on UIQ 2.0 (Symbian OS v7.0)


S60

S60 SDKs enable application development for Symbian OS phones featuring the S60 Platform [3].

The following table shows which edition of S60 works with which version of Symbian OS:
S60 3rd Edition with Feature Pack 2 - Symbian OS v9.3
S60 3rd Edition with Feature Pack 1 - Symbian OS v9.2
S60 3rd Edition - Symbian OS v9.1
S60 2nd Edition with Feature Pack 3 - Symbian OS v8.1
S60 2nd Edition with Feature Pack 2 - Symbian OS v8.0a
S60 2nd Edition with Feature Pack 1 - Symbian OS v7.0s enhanced
S60 2nd Edition - Symbian OS v7.0s
S60 1st Edition - Symbian OS v6.1

SDKs and IDEs needed to develop for S60 can be obtained from Forum Nokia.


Phones based on S60 3rd Edition FP2 (Symbian OS v9.3)
Nokia N96, Samsung I8510 innov8, Samsung L870, Nokia N78


Phones based on S60 3rd Edition FP1 (Symbian OS v9.2)


Phones based on S60 3rd (Symbian OS v9.1)


Phones based on S60 2nd Edition FP3 (Symbian OS v8.1)
Nokia N70, Nokia N90
Phones based on S60 2nd Edition FP2 (Symbian OS v8.0a)
Nokia 6630, Lenovo P930, Nokia 6680, Nokia 6681, Nokia 6682

Phones based on S60 2nd Edition FP1 (Symbian OS v7.0s enhanced)
Nokia 3230, Nokia 6670, Nokia 7610, Nokia 6620, Nokia 6260, Panasonic X700, Panasonic X800, Samsung SDH-D720

Phones based on S60 2nd Edition (Symbian OS v7.0s)

References
E-Books
Symbian OS C++ for Mobile Phones
Symbian OS Explained Effective C++ Programming for Smartphones

Research in Symbian OS at University of OULU

History

University of Oulu is a science community of 3,100 employees and over 15,800 students. The university has a large scientific base of nine educational areas, which are organized in six faculties. The focus areas that encompass the entire university are Biotechnology, Information technology, Northern and Environmental Issues. A suitable work environment and excellent research equipment enable research that requires state-of-the-art technology. The outstanding achievements of information technology have created a center of IT technology in the Oulu region. This "Oulu phenomenon" is a constant marvel for visitors from all over the world.
Involvement with Symbian
Department of Information processing science started teaching Symbian related courses already at the end of 1990's, supported initially by Nokia. The first course, EPOC programming, has been offered continuously, nowadays named Symbian programming. Later, department has actively participated in the development and implementation of the course Mobile systems programming.

This networked course between several Finnish universities has originated from and coordinated by the Tampere University of Technology.

Symbian OS has also been presented as part of other courses such as testing and mobile services development. Department is also part of the MobEdu network of academics, focusing on development of Symbian related teaching material. Also several research groups (e.g. INTERACT) and projects (e.g. IPCity, Capnet, Rooster, Minne, Monica, Nomadic media) relate to mobility and have used also Symbian based devices in the development and testing of mobile technologies and services.
University members engaged with Symbian
- Peter Antoniac, PhD, Assistant Professor, Dept. of Information Processing Science
- Antti Juustila, Phil Lic, Researcher, Dept. of Information Processing Science
- Toni Räisänen, Assistant teacher, Dept. of Information Processing Science
- Kimmo Romppanen, Teaching Assistant, Dept. of Information Processing Science

- Antti Juustila

Antti Juustila is doing research in different areas of Symbian OS and he is also teaching different courses at the Oulu University. He has also supervised different projects. All the details can be found on this web page:
http://www.tol.oulu.fi/users/antti.juustila/

Example Projects

Simple music player application for S60 2nd Edition
This is a small application where you can create playlists which contain songs. There are two forms for inputting/editing playlist and song data. Then you can start playing the music, seeing a small animated dancer moving while music is played. Playing is done using CMdaAudioPlayerUtility. Features GUI, file handling, active objects, timers, audio playing, using Forms for data entry, S60 application framework.
Monopoly game for S60 2nd Edition
A simple text based GUI for playing a simple form of a Monopoly game. Have two views, of which the other is not used in the game but left for you to implement and use for some purpose. Features GUI, file handling (text file), using TLex for parsing, active objects and timers, using the Visitor design pattern to visit a circular list data structure.
Memory game for S60 2nd Edition
This is a small game where the user has to open a pair of “cards” and if they match, they are left open. If they do not match, they are hidden and you try again. When all the cards have been opened, the game is finished. Time is taken and a top ten list is maintained of the best players. Features GUI, file handling, timers, active objects, S60 application framework, dialogs.
Mobile Media Collector
A mobile tool for collecting location based media using Nokia Symbian smart phones. The idea is to provide means to record stories (in wav files) on the phone so that the GPS location of the story is saved together with the author name and date/time of the story. This media file and the associated metadata is then uploaded to a HMDB (HyperMedia DataBase) server. Then you can use a browser and Google Maps to view the location based media. Alternatively Google Earth can also be used. The server side HMDB and KML export support has been developed by a colleague, Toni Räisänen, as part of the Studio’n'Site and IPCity research projects.
The MMC is a Symbian S60 application developed with C++ and uses the phone’s camera, integrated GPS and microphone to record location based stories and pictures. The phone’s data connection (be it GPRS, EDGE, 3G or WLAN) is then used to upload the media to a web service for later use. The tool also records user actions for research purposes.
The tool (Mobile Media Collector; MMC or Tell-a-story (Kerro Tarina in Finnish)) was trialed in Sevettijärvi by 10 school children during September and October. The kids (from 3rd to 9th grade) collected about 90 stories and associated photographs for a group of architecture students. These stories and images of the children’s’ everyday living environment are then used by the architects in their planning of land use in Sevettijärvi. I’ve still not finished analyzing the results of the experiments, so nothing to tell about it here yet.
Meanwhile, I’ve also enhanced the application with new features. Most important one is the Radar view (screenshot below). This view allows the users to view the content while moving about the area where user generated content exists. So when the architect goes back to Sevettijärvi, he or she is able to walk about the area and listen to the kids’ stories where they were actually told, with accompanying photos they took. Maybe this brings additional insights to the planning process. Surely it gives the inhabitants (kids in this case) a possibility to influence the planning process by offering local views of the place to the planners and architects.
The image below shows the basic Radar view contents. The center of the radar shows the position of the user holding the phone. Small yellow circles indicate positions of sound recordings (stories) as small red rectangles indicate photographs. All this content is parsed from a KML file downloaded from the HMDB. The upper left corner displays the name of the person who told the currently selected story (Antti in this example; selection is indicated by drawing a white circle/rectangle around the selected place mark), upper right corner indicates the date the selected story was told. Lower right corner tells the distance of the user from the place the story was told at. North is always up. The lower left corner indicates the distance between the green circles of the radar view, 216 meters in this example. User is able to zoom in and out of the view so that up to 20 km can be viewed in a screenful.
.

When a place mark is selected, the associated media file is downloaded from the HMDB using http. A magenta colored radar beam starts to circle around the screen while the download is commencing (image below). When a sound file has been downloaded, the beam turns to yellow and indicates playback of the sound file (image below). If an image was downloaded instead of a sound file it is then shown on the screen. If the media file has been downloaded before, the local file is used instead.

As the user moves around, the position is updated automatically and new place marks become visible. Also, if the user travels far enough, the content from the HMDB is automatically reloaded to get access to place marks which should now be visible in the Radar screen. Also the server side has been taken further. Now the Google Maps (as well as Earth) provides a neater view to the uploaded data than in the last post of mine.