Home · All Classes · Main Classes · Grouped Classes · Modules · Functions

Qtopia Core Performance Tuning

When building embedded applications on low-powered devices, Qtopia Core provides a number of options that reduce the memory and/or CPU requirements by making various trade-offs. These options range from variations in programming style, to linking and memory allocation.

But note that the most direct way of saving resources, is to avoid compiling in features that are not required. See the fine tuning features documentation for details.

• Programming Style
• Static vs. Dynamic Linking
• Alternative Memory Allocation
• Bypassing the Backing Store

Programming Style

Rather than creating dialogs and widgets every time they are needed, and delete them when they are no longer required, create them once and use the QWidget::hide() and QWidget::show() functions whenever appropiate. To avoid a slow startup of the application, delay the creation of dialogs and widgets until they are requested. All this will improve the CPU performance, it requires a little more memory, but will be much faster.

Static vs. Dynamic Linking

A lot of CPU and memory is used by the ELF (Executable and Linking Format) linking process. Significant savings can be achieved by using a static build of the application suite; rather than having a collection of executables which link dynamically to Qt's libraries, all the applications is built into into a single executable which is statically linked to Qt's libraries.

This improves the start-up time and reduces memory usage at the expense of flexibility (to add a new application, you must recompile the single executable) and robustness (if one application has a bug, it might harm other applications).

 ./configure -static

When installing end-user applications, this approach may not be an option, but when building a single application suite for a device with limited CPU power and memory, this option could be very beneficial.

Alternative Memory Allocation

The libraries shipped with some C++ compilers on some platforms have poor performance in the built-in "new" and "delete" operators. Improved memory allocation and performance may be gained by re-implementing these functions:

 void *operator new[](size_t size)
 {
     return malloc(size);
 }

 void *operator new(size_t size)
 {
     return malloc(size);
 }

 void operator delete[](void *ptr)
 {
     free(ptr);
 }

 void operator delete[](void *ptr, size_t)
 {
     free(ptr);
 }

 void operator delete(void *ptr)
 {
     free(ptr);
 }

 void operator delete(void *ptr, size_t)
 {
     free(ptr);
 }

The example above shows the necessary code to switch to the plain C memory allocators.

Bypassing the Backing Store

When rendering, Qt uses the concept of a backing store; i.e., a paint buffer, to reduce flicker and to support graphics operations such as blending.

Qtopia Core's default behavior is for each client to render its widgets into memory while the server is responsible for putting the contents of the memory onto the screen. But when the hardware is known and well defined, as is often the case with software for embedded devices, it might be useful to bypass the backing store, allowing the clients to manipulate the underlying hardware directly. There are two approaches to direct painting: The first approach is to set the Qt::WA_PaintOnScreen window attribute for each widget, the other is to use the QDirectPainter class to reserve a region of the framebuffer. For more information, see the direct painting section of the architecture documentation.