Question

When building embedded applications on low-powered devices, a number of options are available that would not be considered in a desktop application environment. These options reduce the memory and/or CPU requirements at the cost of other factors.

• Tuning the functionality of Qt
• General programming style
• Static vs. Dynamic linking
• Alternative memory allocation

General programming style

The following guidelines will improve CPU performance:

• Create dialogs and widgets once, then QWidget::hide() and QWidget::show() them, rather than creating them and deleting them every time they are needed. This will use a little more memory, but will be much faster. Try to create them the first time "lazily" to avoid slow startup (only create the Find dialog the first time the user invokes it).

Static vs. Dynamic linking

Much CPU and memory is used by the ELF linking process. You can make significant savings by using a static build of your application suite. This means that rather than having a dynamic library (libqte.so) and a collection of executables which link dynamically to that library, you build all the applications into a single executable and statically link that with a static library (libqt.a). This improves 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). If you need to install end-user applications, this may not be an option, but if you are building a single application suite for a device with limited CPU power and memory, this option could be very beneficial.

To compile Qt as a static library, add the -static options when you run configure.

To build your application suite as an all-in-one application, design each application as a stand-alone widget or set of widgets, with only minimal code in the main() function. Then, write an application that gives some way to switch between the applications (eg. a QIconView). The QPE is an example of this. It can be built either as a set of dynamically-linked executables, or as a single static application.

Note that you should generally still link dynamically against the standard C library and any other libraries which might be used by other applications on your device.

Alternative memory allocation

We have found that the libraries shipped with some C++ compilers on some platforms have poor performance in the built-in "new" and "delete" operators. You might gain performance by re-implementing these functions. For example, you can switch to the plain C allocators by adding the following to your code:

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

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

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

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

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

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