0
|
1 |
/****************************************************************************
|
|
2 |
**
|
|
3 |
** Copyright (C) 2009 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 |
*/
|