source: trunk/doc/src/platforms/emb-performance.qdoc@ 846

Last change on this file since 846 was 846, checked in by Dmitry A. Kuminov, 14 years ago

trunk: Merged in qt 4.7.2 sources from branches/vendor/nokia/qt.

  • Property svn:eol-style set to native
File size: 5.6 KB
Line 
1/****************************************************************************
2**
3** Copyright (C) 2011 Nokia Corporation and/or its subsidiary(-ies).
4** All rights reserved.
5** Contact: Nokia Corporation ([email protected])
6**
7** This file is part of the documentation of the Qt Toolkit.
8**
9** $QT_BEGIN_LICENSE:FDL$
10** Commercial Usage
11** Licensees holding valid Qt Commercial licenses may use this file in
12** accordance with the Qt Commercial License Agreement provided with the
13** Software or, alternatively, in accordance with the terms contained in a
14** written agreement between you and Nokia.
15**
16** GNU Free Documentation License
17** Alternatively, this file may be used under the terms of the GNU Free
18** Documentation License version 1.3 as published by the Free Software
19** Foundation and appearing in the file included in the packaging of this
20** file.
21**
22** If you have questions regarding the use of this file, please contact
23** Nokia at [email protected].
24** $QT_END_LICENSE$
25**
26****************************************************************************/
27
28/*!
29 \page qt-performance.html
30 \title Qt Performance Tuning
31 \ingroup qtce
32 \ingroup qt-embedded-linux
33 \brief Ways to improve performance on embedded platforms.
34
35 When building embedded applications on low-powered devices,
36 \l{Qt for Windows CE} and \l{Qt for Embedded Linux} provide
37 a number of options that reduce the memory and/or CPU requirements
38 by making various trade-offs. These options range from variations
39 in programming style, to linking and memory allocation.
40
41 Note that the most direct way of saving resources, is to avoid compiling
42 in features that are not required. See the \l{Fine-Tuning Features in Qt}
43 {fine tuning features} documentation for details.
44
45 \tableofcontents
46
47 \section1 Programming Style
48
49 Rather than creating dialogs and widgets every time they are
50 needed, and delete them when they are no longer required, create
51 them once and use the QWidget::hide() and QWidget::show()
52 functions whenever appropriate. To avoid a slow startup of the
53 application, delay the creation of dialogs and widgets until they
54 are requested. All this will improve the CPU performance, it
55 requires a little more memory, but will be much faster.
56
57 \section1 Static vs. Dynamic Linking
58
59 A lot of CPU and memory is used by the ELF (Executable and Linking
60 Format) linking process. Significant savings can be achieved by
61 using a static build of the application suite; rather than having
62 a collection of executables which link dynamically to Qt's
63 libraries, all the applications is built into into a single
64 executable which is statically linked to Qt's libraries.
65
66 This improves the start-up time and reduces memory usage at the
67 expense of flexibility (to add a new application, you must
68 recompile the single executable) and robustness (if one
69 application has a bug, it might harm other applications).
70
71 \table 100%
72 \row
73 \o \bold {Creating a Static Build}
74
75 To compile Qt as a static library, use the \c -static option when
76 running configure:
77
78 \snippet doc/src/snippets/code/doc_src_emb-performance.qdoc 0
79
80 To build the application suite as an all-in-one application,
81 design each application as a stand-alone widget (or set of
82 widgets) with only minimal code in the \c main() function. Then,
83 write an application that provides a means of switching between
84 the applications. The \l Qt Extended platform is an example using this
85 approach: It can be built either as a set of dynamically linked
86 executables, or as a single static application.
87
88 Note that the application still should link dynamically against
89 the standard C library and any other libraries which might be used
90 by other applications on the target device.
91
92 \endtable
93
94 When installing end-user applications, this approach may not be an
95 option, but when building a single application suite for a device
96 with limited CPU power and memory, this option could be very
97 beneficial.
98
99 \section1 Alternative Memory Allocation
100
101 The libraries shipped with some C++ compilers on some platforms
102 have poor performance in the built-in "new" and "delete"
103 operators. Improved memory allocation and performance may be
104 gained by re-implementing these functions: