|
1 /**************************************************************************** |
|
2 ** |
|
3 ** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies). |
|
4 ** All rights reserved. |
|
5 ** Contact: Nokia Corporation (qt-info@nokia.com) |
|
6 ** |
|
7 ** This file is part of the documentation of the Qt Toolkit. |
|
8 ** |
|
9 ** $QT_BEGIN_LICENSE:LGPL$ |
|
10 ** No Commercial Usage |
|
11 ** This file contains pre-release code and may not be distributed. |
|
12 ** You may use this file in accordance with the terms and conditions |
|
13 ** contained in the Technology Preview License Agreement accompanying |
|
14 ** this package. |
|
15 ** |
|
16 ** GNU Lesser General Public License Usage |
|
17 ** Alternatively, this file may be used under the terms of the GNU Lesser |
|
18 ** General Public License version 2.1 as published by the Free Software |
|
19 ** Foundation and appearing in the file LICENSE.LGPL included in the |
|
20 ** packaging of this file. Please review the following information to |
|
21 ** ensure the GNU Lesser General Public License version 2.1 requirements |
|
22 ** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html. |
|
23 ** |
|
24 ** In addition, as a special exception, Nokia gives you certain additional |
|
25 ** rights. These rights are described in the Nokia Qt LGPL Exception |
|
26 ** version 1.1, included in the file LGPL_EXCEPTION.txt in this package. |
|
27 ** |
|
28 ** If you have questions regarding the use of this file, please contact |
|
29 ** Nokia at qt-info@nokia.com. |
|
30 ** |
|
31 ** |
|
32 ** |
|
33 ** |
|
34 ** |
|
35 ** |
|
36 ** |
|
37 ** |
|
38 ** $QT_END_LICENSE$ |
|
39 ** |
|
40 ****************************************************************************/ |
|
41 |
|
42 /*! |
|
43 \page qt-performance.html |
|
44 \title Qt Performance Tuning |
|
45 \ingroup qtce |
|
46 \ingroup qt-embedded-linux |
|
47 \brief Ways to improve performance on embedded platforms. |
|
48 |
|
49 When building embedded applications on low-powered devices, |
|
50 \l{Qt for Windows CE} and \l{Qt for Embedded Linux} provide |
|
51 a number of options that reduce the memory and/or CPU requirements |
|
52 by making various trade-offs. These options range from variations |
|
53 in programming style, to linking and memory allocation. |
|
54 |
|
55 Note that the most direct way of saving resources, is to avoid compiling |
|
56 in features that are not required. See the \l{Fine-Tuning Features in Qt} |
|
57 {fine tuning features} documentation for details. |
|
58 |
|
59 \tableofcontents |
|
60 |
|
61 \section1 Programming Style |
|
62 |
|
63 Rather than creating dialogs and widgets every time they are |
|
64 needed, and delete them when they are no longer required, create |
|
65 them once and use the QWidget::hide() and QWidget::show() |
|
66 functions whenever appropriate. To avoid a slow startup of the |
|
67 application, delay the creation of dialogs and widgets until they |
|
68 are requested. All this will improve the CPU performance, it |
|
69 requires a little more memory, but will be much faster. |
|
70 |
|
71 \section1 Static vs. Dynamic Linking |
|
72 |
|
73 A lot of CPU and memory is used by the ELF (Executable and Linking |
|
74 Format) linking process. Significant savings can be achieved by |
|
75 using a static build of the application suite; rather than having |
|
76 a collection of executables which link dynamically to Qt's |
|
77 libraries, all the applications is built into into a single |
|
78 executable which is statically linked to Qt's libraries. |
|
79 |
|
80 This improves the start-up time and reduces memory usage at the |
|
81 expense of flexibility (to add a new application, you must |
|
82 recompile the single executable) and robustness (if one |
|
83 application has a bug, it might harm other applications). |
|
84 |
|
85 \table 100% |
|
86 \row |
|
87 \o \bold {Creating a Static Build} |
|
88 |
|
89 To compile Qt as a static library, use the \c -static option when |
|
90 running configure: |
|
91 |
|
92 \snippet doc/src/snippets/code/doc_src_emb-performance.qdoc 0 |
|
93 |
|
94 To build the application suite as an all-in-one application, |
|
95 design each application as a stand-alone widget (or set of |
|
96 widgets) with only minimal code in the \c main() function. Then, |
|
97 write an application that provides a means of switching between |
|
98 the applications. The \l Qt Extended platform is an example using this |
|
99 approach: It can be built either as a set of dynamically linked |
|
100 executables, or as a single static application. |
|
101 |
|
102 Note that the application still should link dynamically against |
|
103 the standard C library and any other libraries which might be used |
|
104 by other applications on the target device. |
|
105 |
|
106 \endtable |
|
107 |
|
108 When installing end-user applications, this approach may not be an |
|
109 option, but when building a single application suite for a device |
|
110 with limited CPU power and memory, this option could be very |
|
111 beneficial. |
|
112 |
|
113 \section1 Alternative Memory Allocation |
|
114 |
|
115 The libraries shipped with some C++ compilers on some platforms |
|
116 have poor performance in the built-in "new" and "delete" |
|
117 operators. Improved memory allocation and performance may be |
|
118 gained by re-implementing these functions: |
|
119 |
|
120 \snippet doc/src/snippets/code/doc_src_emb-performance.qdoc 1 |
|
121 |
|
122 The example above shows the necessary code to switch to the plain |
|
123 C memory allocators. |
|
124 |
|
125 \section1 Bypassing the Backing Store |
|
126 |
|
127 When rendering, Qt uses the concept of a backing store; i.e., a |
|
128 paint buffer, to reduce flicker and to support graphics operations |
|
129 such as blending. |
|
130 |
|
131 The default behavior is for each client to render |
|
132 its widgets into memory while the server is responsible for |
|
133 putting the contents of the memory onto the screen. But when the |
|
134 hardware is known and well defined, as is often the case with |
|
135 software for embedded devices, it might be useful to bypass the |
|
136 backing store, allowing the clients to manipulate the underlying |
|
137 hardware directly. |
|
138 \if defined(qtce) |
|
139 This is achieved by setting the Qt::WA_PaintOnScreen window attribute |
|
140 for each widget. |
|
141 \else |
|
142 |
|
143 There are two approaches to direct painting: The first approach is |
|
144 to set the Qt::WA_PaintOnScreen window attribute for each widget, |
|
145 the other is to use the QDirectPainter class to reserve a region |
|
146 of the framebuffer. |
|
147 For more information, see the |
|
148 \l{Qt for Embedded Linux Architecture#Direct Painting}{direct painting} |
|
149 section of the \l{Qt for Embedded Linux Architecture}{architecture} |
|
150 documentation. |
|
151 \endif |
|
152 */ |