From d796c9dd933ab96ec83b9a634feedd5d32e1ba3f Mon Sep 17 00:00:00 2001 From: Timothy Pearson Date: Tue, 8 Nov 2011 12:31:36 -0600 Subject: Test conversion to TQt3 from Qt3 8c6fc1f8e35fd264dd01c582ca5e7549b32ab731 --- doc/html/emb-performance.html | 132 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 132 insertions(+) create mode 100644 doc/html/emb-performance.html (limited to 'doc/html/emb-performance.html') diff --git a/doc/html/emb-performance.html b/doc/html/emb-performance.html new file mode 100644 index 00000000..51904cf1 --- /dev/null +++ b/doc/html/emb-performance.html @@ -0,0 +1,132 @@ + + + + + +TQt/Embedded Performance Tuning + + + + + + + +

TQt/Embedded Performance Tuning

+ + +When building embedded applications on low-powered devices, a number +of options are available that would not be considered in a desktop +application environment. These options reduce the memory and/or CPU +retquirements at the cost of other factors. +

Tuning the functionality of TQt +
General programming style +
Static vs. Dynamic linking +
Alternative memory allocation +

+
+
General programming style +
+
The following guidelines will improve CPU performance: +
+
Create dialogs and widgets once, then TQWidget::hide() and +TQWidget::show() them, rather than creating them and deleting +them every time they are needed. +This will use a little more memory, but will be much faster. +Try to create them the first time "lazily" to avoid slow +startup (e.g. only create a Find dialog the first time the +user invokes it). +
+
+
Static vs. Dynamic linking +
+
A lot of CPU and memory is used by the ELF linking process. You can +make significant savings by using a static build of your application +suite. This means that rather than having a dynamic library (libqte.so) and a collection of executables which link dynamically to +that library, you build all the applications into a single executable +and statically link that with a static library (libqt.a). This +improves 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). If you need to install end-user +applications, this may not be an option, but if you are building a +single application suite for a device with limited CPU power and +memory, this option could be very beneficial. +
To compile TQt as a static library, add the -static options when +you run configure. +
To build your 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 main() function. Then, write an application that gives +some way to switch between the applications (e.g. a TQIconView). +TQtopia is an example of this. It can be built either as a set of +dynamically linked executables, or as a single static application. +
Note that you should generally still link dynamically against the +standard C library and any other libraries which might be used by +other applications on your device. +
+
Alternative memory allocation +
+
We have found that the libraries shipped with some C++ compilers on +some platforms have poor performance in the built-in "new" and "delete" +operators. You might gain performance by re-implementing these +functions. For example, you can switch to the plain C allocators +by adding the following to your code: +

+ void* operator new[]( size_t size ) + { + return malloc( size ); + } + + void* operator new( size_t size ) + { + return malloc( size ); + } + + void operator delete[]( void *p ) + { + free( p ); + } + + void operator delete[]( void *p, size_t size ) + { + free( p ); + } + + void operator delete( void *p ) + { + free( p ); + } + + void operator delete( void *p, size_t size ) + { + free( p ); + } +
+ + + +
+ +
Copyright © 2007 +Trolltech Trademarks +
TQt 3.3.8
+
+ -- cgit v1.2.3