Viadeo Twitter Google Bookmarks ! Facebook Digg del.icio.us MySpace Yahoo MyWeb Blinklist Netvouz Reddit Simpy StumbleUpon Bookmarks Windows Live Favorites 
Logo Documentation Qt ·  Page d'accueil  ·  Tous les espaces de nom  ·  Toutes les classes  ·  Classes principales  ·  Annotées  ·  Classes groupées  ·  Modules  ·  Fonctions  · 

Qt for Embedded Linux Performance Tuning

When building embedded applications on low-powered devices, Qt for Embedded Linux 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

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 appropriate. 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).

Creating a Static Build

To compile Qt as a static library, use the -static option when running configure:

 ./configure -static

To build the 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 provides a means of switching between the applications. The Qt Extended platform is an example using this approach: It can be built either as a set of dynamically linked executables, or as a single static application.

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

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.

The 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.

Publicité

Best Of

Actualités les plus lues

Semaine
Mois
Année
  1. « Quelque chose ne va vraiment pas avec les développeurs "modernes" », un développeur à "l'ancienne" critique la multiplication des bibliothèques 102
  2. Pourquoi les programmeurs sont-ils moins payés que les gestionnaires de programmes ? Manquent-ils de pouvoir de négociation ? 53
  3. «Le projet de loi des droits du développeur» : quelles conditions doivent remplir les entreprises pour que le développeur puisse réussir ? 73
  4. Les développeurs détestent-ils les antivirus ? Un programmeur manifeste sa haine envers ces solutions de sécurité 27
  5. Qt Commercial : Digia organise un webinar gratuit le 27 mars sur la conception d'interfaces utilisateur et d'applications avec le framework 0
  6. Quelles nouveautés de C++11 Visual C++ doit-il rapidement intégrer ? Donnez-nous votre avis 10
  7. 2017 : un quinquennat pour une nouvelle version du C++ ? Possible, selon Herb Sutter 11
Page suivante
  1. Linus Torvalds : le "C++ est un langage horrible", en justifiant le choix du C pour le système de gestion de version Git 100
  2. Comment prendre en compte l'utilisateur dans vos applications ? Pour un développeur, « 90 % des utilisateurs sont des idiots » 229
  3. Quel est LE livre que tout développeur doit lire absolument ? Celui qui vous a le plus marqué et inspiré 96
  4. Apple cède et s'engage à payer des droits à Nokia, le conflit des brevets entre les deux firmes s'achève 158
  5. Nokia porte à nouveau plainte contre Apple pour violation de sept nouveaux brevets 158
  6. Quel est le code dont vous êtes le plus fier ? Pourquoi l'avez-vous écrit ? Et pourquoi vous a-t-il donné autant de satisfaction ? 83
  7. « Quelque chose ne va vraiment pas avec les développeurs "modernes" », un développeur à "l'ancienne" critique la multiplication des bibliothèques 101
Page suivante

Le Qt Developer Network au hasard

Logo

Combiner licence, à propos et fermer d'une autre manière

Le Qt Developer Network est un réseau de développeurs Qt anglophone, où ils peuvent partager leur expérience sur le framework. Lire l'article.

Communauté

Ressources

Liens utiles

Contact

  • Vous souhaitez rejoindre la rédaction ou proposer un tutoriel, une traduction, une question... ? Postez dans le forum Contribuez ou contactez-nous par MP ou par email (voir en bas de page).

Qt dans le magazine

Cette page est une traduction d'une page de la documentation de Qt, écrite par Nokia Corporation and/or its subsidiary(-ies). Les éventuels problèmes résultant d'une mauvaise traduction ne sont pas imputables à Nokia. Qt 4.4
Copyright © 2012 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon, vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E de dommages et intérêts. Cette page est déposée à la SACD.
Vous avez déniché une erreur ? Un bug ? Une redirection cassée ? Ou tout autre problème, quel qu'il soit ? Ou bien vous désirez participer à ce projet de traduction ? N'hésitez pas à nous contacter ou par MP !
 
 
 
 
Partenaires

Hébergement Web