Performance TuningWhen building embedded applications on low-powered devices, a number of options are available 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 Fine-Tuning Features for details. Programming StyleRather 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 a slow startup of the application, delay the creation of dialogs and widgets until they are requested. This will improve CPU performance: The approach requires a little more memory, but will be much faster. Static vs. Dynamic LinkingA 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. This means that rather than having dynamic Qt libraries and a collection of executables which link dynamically to these libraries, all the applications is built into into a single executable which is statically linked to static Qt 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).
The Qtopia platform is an example using this apporach: It can be built either as a set of dynamically linked executables, or as a single static application. 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 AllocationThe 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. |
Publicité
Best OfActualités les plus luesSemaine
Mois
Année
Le Qt Quarterly au hasardPoppler : afficher des fichiers PDF avec QtQt Quarterly est la revue trimestrielle proposée par Nokia et à destination des développeurs Qt. Ces articles d'une grande qualité technique sont rédigés par des experts Qt. Lire l'article.
CommunautéRessources
Liens utilesContact
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.1 | |
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 ! |
Copyright © 2000-2012 - www.developpez.com