diff options
Diffstat (limited to 'doc/src/emb-performance.qdoc')
| -rw-r--r-- | doc/src/emb-performance.qdoc | 152 |
1 files changed, 152 insertions, 0 deletions
diff --git a/doc/src/emb-performance.qdoc b/doc/src/emb-performance.qdoc new file mode 100644 index 0000000..79edf34 --- /dev/null +++ b/doc/src/emb-performance.qdoc @@ -0,0 +1,152 @@ +/**************************************************************************** +** +** Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies). +** Contact: Qt Software Information (qt-info@nokia.com) +** +** This file is part of the documentation of the Qt Toolkit. +** +** $QT_BEGIN_LICENSE:LGPL$ +** No Commercial Usage +** This file contains pre-release code and may not be distributed. +** You may use this file in accordance with the terms and conditions +** contained in the either Technology Preview License Agreement or the +** Beta Release License Agreement. +** +** GNU Lesser General Public License Usage +** Alternatively, this file may be used under the terms of the GNU Lesser +** General Public License version 2.1 as published by the Free Software +** Foundation and appearing in the file LICENSE.LGPL included in the +** packaging of this file. Please review the following information to +** ensure the GNU Lesser General Public License version 2.1 requirements +** will be met: http://www.gnu.org/licenses/old-licenses/lgpl-2.1.html. +** +** In addition, as a special exception, Nokia gives you certain +** additional rights. These rights are described in the Nokia Qt LGPL +** Exception version 1.0, included in the file LGPL_EXCEPTION.txt in this +** package. +** +** GNU General Public License Usage +** Alternatively, this file may be used under the terms of the GNU +** General Public License version 3.0 as published by the Free Software +** Foundation and appearing in the file LICENSE.GPL included in the +** packaging of this file. Please review the following information to +** ensure the GNU General Public License version 3.0 requirements will be +** met: http://www.gnu.org/copyleft/gpl.html. +** +** If you are unsure which license is appropriate for your use, please +** contact the sales department at qt-sales@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 +*/ |