1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
|
/****************************************************************************
**
** Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
** All rights reserved.
** Contact: Nokia Corporation (qt-info@nokia.com)
**
** This file is part of the documentation of the Qt Toolkit.
**
** $QT_BEGIN_LICENSE:FDL$
** Commercial Usage
** Licensees holding valid Qt Commercial licenses may use this file in
** accordance with the Qt Commercial License Agreement provided with the
** Software or, alternatively, in accordance with the terms contained in a
** written agreement between you and Nokia.
**
** GNU Free Documentation License
** Alternatively, this file may be used under the terms of the GNU Free
** Documentation License version 1.3 as published by the Free Software
** Foundation and appearing in the file included in the packaging of this
** file.
**
** If you have questions regarding the use of this file, please contact
** Nokia at qt-info@nokia.com.
** $QT_END_LICENSE$
**
****************************************************************************/
/*!
\page qt-performance.html
\title Qt Performance Tuning
\ingroup qtce
\ingroup qt-embedded-linux
\brief Ways to improve performance on embedded platforms.
When building embedded applications on low-powered devices,
\l{Qt for Windows CE} and \l{Qt for Embedded Linux} provide
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.
Note that the most direct way of saving resources, is to avoid compiling
in features that are not required. See the \l{Fine-Tuning Features in Qt}
{fine tuning features} documentation for details.
\tableofcontents
\section1 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.
\section1 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).
\table 100%
\row
\o \bold {Creating a Static Build}
To compile Qt as a static library, use the \c -static option when
running configure:
\snippet doc/src/snippets/code/doc_src_emb-performance.qdoc 0
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 \c main() function. Then,
write an application that provides a means of switching between
the applications. The \l 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.
\endtable
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.
\section1 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:
\snippet doc/src/snippets/code/doc_src_emb-performance.qdoc 1
The example above shows the necessary code to switch to the plain
C memory allocators.
\section1 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.
\if defined(qtce)
This is achieved by setting the Qt::WA_PaintOnScreen window attribute
for each widget.
\else
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
\l{Qt for Embedded Linux Architecture#Direct Painting}{direct painting}
section of the \l{Qt for Embedded Linux Architecture}{architecture}
documentation.
\endif
*/
|
