|
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
|
|
<!-- /home/espenr/tmp/qt-3.3.8-espenr-2499/qt-x11-free-3.3.8/doc/qws.doc:532 -->
|
|
|
|
<html>
|
|
|
|
<head>
|
|
|
|
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
|
|
|
|
<title>TQt/Embedded Performance Tuning</title>
|
|
|
|
<style type="text/css"><!--
|
|
|
|
fn { margin-left: 1cm; text-indent: -1cm; }
|
|
|
|
a:link { color: #004faf; text-decoration: none }
|
|
|
|
a:visited { color: #672967; text-decoration: none }
|
|
|
|
body { background: #ffffff; color: black; }
|
|
|
|
--></style>
|
|
|
|
</head>
|
|
|
|
<body>
|
|
|
|
|
|
|
|
<table border="0" cellpadding="0" cellspacing="0" width="100%">
|
|
|
|
<tr bgcolor="#E5E5E5">
|
|
|
|
<td valign=center>
|
|
|
|
<a href="index.html">
|
|
|
|
<font color="#004faf">Home</font></a>
|
|
|
|
| <a href="classes.html">
|
|
|
|
<font color="#004faf">All Classes</font></a>
|
|
|
|
| <a href="mainclasses.html">
|
|
|
|
<font color="#004faf">Main Classes</font></a>
|
|
|
|
| <a href="annotated.html">
|
|
|
|
<font color="#004faf">Annotated</font></a>
|
|
|
|
| <a href="groups.html">
|
|
|
|
<font color="#004faf">Grouped Classes</font></a>
|
|
|
|
| <a href="functions.html">
|
|
|
|
<font color="#004faf">Functions</font></a>
|
|
|
|
</td>
|
|
|
|
<td align="right" valign="center"><img src="logo32.png" align="right" width="64" height="32" border="0"></td></tr></table><h1 align=center>TQt/Embedded Performance Tuning</h1>
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
requirements at the cost of other factors.
|
|
|
|
<p> <ul>
|
|
|
|
<li> <a href="emb-features.html"><b>Tuning the functionality of TQt</a>
|
|
|
|
<li> <a href="#general">General programming style</a>
|
|
|
|
<li> <a href="#static">Static vs. Dynamic linking</a>
|
|
|
|
<li> <a href="#alloc">Alternative memory allocation</a>
|
|
|
|
</ul>
|
|
|
|
<p> <a name="general"></a>
|
|
|
|
<h2> General programming style
|
|
|
|
</h2>
|
|
|
|
<a name="1"></a><p> The following guidelines will improve CPU performance:
|
|
|
|
<ul>
|
|
|
|
<li> Create dialogs and widgets once, then <a href="ntqwidget.html#hide">TQWidget::hide</a>() and
|
|
|
|
<a href="ntqwidget.html#show">TQWidget::show</a>() 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).
|
|
|
|
</ul>
|
|
|
|
<p> <a name="static"></a>
|
|
|
|
<h2> Static vs. Dynamic linking
|
|
|
|
</h2>
|
|
|
|
<a name="2"></a><p> 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 (<tt>libqte.so</tt>) 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 (<tt>libqt.a</tt>). 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.
|
|
|
|
<p> To compile TQt as a static library, add the <tt>-static</tt> options when
|
|
|
|
you run configure.
|
|
|
|
<p> 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 <a href="ntqiconview.html">TQIconView</a>).
|
|
|
|
<a href="http://www.trolltech.com/products/qtopia/index.html">TQtopia</a> is an example of this. It can be built either as a set of
|
|
|
|
dynamically linked executables, or as a single static application.
|
|
|
|
<p> 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.
|
|
|
|
<p> <a name="alloc"></a>
|
|
|
|
<h2> Alternative memory allocation
|
|
|
|
</h2>
|
|
|
|
<a name="3"></a><p> 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:
|
|
|
|
<p> <pre>
|
|
|
|
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 );
|
|
|
|
}
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
|
|
|
|
<!-- eof -->
|
|
|
|
<p><address><hr><div align=center>
|
|
|
|
<table width=100% cellspacing=0 border=0><tr>
|
|
|
|
<td>Copyright © 2007
|
|
|
|
<a href="troll.html">Trolltech</a><td align=center><a href="trademarks.html">Trademarks</a>
|
|
|
|
<td align=right><div align=right>TQt 3.3.8</div>
|
|
|
|
</table></div></address></body>
|
|
|
|
</html>
|