Symbian3/SDK/Source/GUID-16A1C613-288D-471C-8551-51B61290E28F.dita
changeset 7 51a74ef9ed63
child 13 48780e181b38
equal deleted inserted replaced
6:43e37759235e 7:51a74ef9ed63
       
     1 <?xml version="1.0" encoding="utf-8"?>
       
     2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
       
     3 <!-- This component and the accompanying materials are made available under the terms of the License 
       
     4 "Eclipse Public License v1.0" which accompanies this distribution, 
       
     5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
       
     6 <!-- Initial Contributors:
       
     7     Nokia Corporation - initial contribution.
       
     8 Contributors: 
       
     9 -->
       
    10 <!DOCTYPE concept
       
    11   PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
       
    12 <concept id="GUID-16A1C613-288D-471C-8551-51B61290E28F" xml:lang="en"><title>Application
       
    13 Start-Up Time Optimization</title><shortdesc>It is important that phone users do not have to wait long for applications
       
    14 to start. This document summarizes the techniques for optimizing application
       
    15 start-up time.</shortdesc><prolog><metadata><keywords/></metadata></prolog><conbody>
       
    16 <section id="GUID-4585EAA0-4169-4C5C-A7AD-AAA7FDA529C6">       <title>Introduction</title> 
       
    17      <p>The techniques discussed in this document are limited in scope to
       
    18 application programming. In other words, they do not require modification
       
    19 of any core OS components or servers. Some of the techniques are general good
       
    20 practice and are useful to developers at all levels. </p>     <p>The techniques
       
    21 can be summarized as follows:</p><ul>
       
    22 <li><p>Avoid causing unnecessary code to be executed as an effect of your
       
    23 code.</p></li>
       
    24 <li><p>Defer construction of objects, loading of dynamic libraries (for example,
       
    25 the application model), and starting servers until you need to use them.</p></li>
       
    26 <li><p>Write efficient code!</p></li>
       
    27 </ul><note>There is an inevitable trade-off between shortening the start-up
       
    28 time and introducing latency elsewhere in the application. For example, if
       
    29 you don’t connect to a server at start-up, you will have to do it later on,
       
    30 when the application needs to use the server. This may be overcome by a central
       
    31 component that coordinates background connections, or construction, such as
       
    32 the view server.</note></section>
       
    33 <section id="GUID-818EB735-F408-47D9-9759-A180766996B4"><title>Measure start-up
       
    34 time before you start optimizing</title><p>Do not assume you know which methods
       
    35 take the most time. Pay close attention to iterative and recursive operations.
       
    36 Many useful tools and techniques are available to help identify poorly performing
       
    37 code:</p><ul>
       
    38 <li><p>Software analysis tools, for instance <xref href="http://www.glowcode.com.dita">GlowCode</xref> and
       
    39 MetroWerks <xref href="http://www.metrowerks.com/MW/Develop/AMC/CodeTEST/default.htm.dita">CodeTEST</xref></p></li>
       
    40 <li><p>The Symbian profiling tool, profiler.exe, which is supplied on DevKits </p></li>
       
    41 <li><p>The RDebug class provides some profiling functions </p></li>
       
    42 <li><p>The TTime class can be used to time blocks of code, but beware of context
       
    43 switches, otherwise you may end up timing other threads!</p></li>
       
    44 <li><p>Deliberately slowing down suspect blocks of code can reveal whether
       
    45 or not optimizing it would bring a significant performance improvement. </p></li>
       
    46 </ul></section>
       
    47 <section id="GUID-594EC7CB-3477-4D0F-B489-8C1A42ED0789"><title>Defer construction
       
    48 of the application model and other data members</title><p>Many applications
       
    49 instantiate their components, for instance error handlers, dialogs and menus,
       
    50 during start-up. In turn, each of these components may instantiate other components,
       
    51 for instance menu resources and icons. This can bring some benefits, for instance
       
    52 reducing application complexity, revealing memory allocation problems at start-up
       
    53 rather than after the application has been running for some time and improving
       
    54 the runtime performance of the application. However, to minimize application
       
    55 start-up time, it is recommended to avoid this behavior. Your goal should
       
    56 be to only do what is immediately necessary during start-up. </p></section>
       
    57 <section id="GUID-F7BE9B30-1993-4736-9E88-F0E065BE1A3C"><title>Draw the application
       
    58 as quickly as possible</title><p>During application start-up, only construct
       
    59 UI components that appear in the application’s initial view. This applies
       
    60 especially to the application's implementations of <codeph>CXxxApplication::CreateDocumentL()</codeph>, <codeph>CXxxDocument::ConstructL()</codeph> and <codeph>CXxxDocument::CreateAppUiL()</codeph>, all of which are called
       
    61 before <codeph>CXxxAppUi::ConstructL()</codeph>. Do not read bitmaps, resources,
       
    62 or any other data associated with the UI from files unless it is necessary.</p><p>In <codeph>CXxxAppUi::ConstructL()</codeph>,
       
    63 make sure <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-C79D0B6F-C2D7-3F22-A62B-88762092E869"><apiname>CCoeControl::ActivateL()</apiname></xref> and <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-D5458F8C-E199-37DD-B821-050B749122C6"><apiname>CCoeControl::DrawNow()</apiname></xref> are
       
    64 called on all controls that must be drawn when the application is launched.
       
    65 Also ensure that the client-side window server command buffer is flushed by
       
    66 calling <codeph>Flush()</codeph> on the application's window server session.
       
    67 This ensures that there aren't any drawing commands left in the client-side
       
    68 buffer, after <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-D5458F8C-E199-37DD-B821-050B749122C6"><apiname>CCoeControl::DrawNow()</apiname></xref> has completed. </p></section>
       
    69 <section id="GUID-B320F7A3-C0E3-4A3D-8B45-AEFEDFBAAD2E"><title>Minimize the
       
    70 number of bitmaps used by GUI components</title><p>Often, when a large number
       
    71 of small images are required by an application, the overhead associated with
       
    72 loading each bitmap outweighs any benefit associated with their size. Some
       
    73 possible ways to avoid this are: </p><ul>
       
    74 <li><p>use text instead, </p></li>
       
    75 <li><p>for very simple graphics, draw directly using drawing primitives rather
       
    76 than loading a bitmap,  </p></li>
       
    77 <li><p>concatenate many small bitmaps into one large bitmap file to reduce
       
    78 the need to search for and load multiple files.</p></li>
       
    79 </ul></section>
       
    80 <section id="GUID-F00BA3FF-D9BD-44DF-A284-BAF5701179D8"><title>Reduce the
       
    81 number of redraws</title><p>Some GUI components redraw themselves every time
       
    82 their data changes. This may not always be necessary. Complicated GUI components
       
    83 should implement their<codeph>Draw()</codeph> method to only update the area
       
    84 of the screen that has changed. For example, there is no point in redrawing
       
    85 a whole list box every time a new item is appended to it. In such cases, a
       
    86 GUI API should allow you to switch off redrawing. Beware of GUI methods that
       
    87 cause the object they are called upon to redraw itself.</p><p>Use <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-9FB682AC-0209-302A-83F3-7BCB1162B998"><apiname>CCoeControl::DrawDeferred()</apiname></xref> in
       
    88 preference to <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-D5458F8C-E199-37DD-B821-050B749122C6"><apiname>CCoeControl::DrawNow()</apiname></xref> if possible, because
       
    89 excessive use of <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-D5458F8C-E199-37DD-B821-050B749122C6"><apiname>CCoeControl::DrawNow()</apiname></xref> can cause GUI flicker.
       
    90 For an explanation, see the documentation for <xref href="GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160.dita#GUID-B06F99BD-F032-3B87-AB26-5DD6EBE8C160/GUID-9FB682AC-0209-302A-83F3-7BCB1162B998"><apiname>CCoeControl::DrawDeferred()</apiname></xref>. </p></section>
       
    91 <section id="GUID-71443827-BF8D-4BD8-8136-5023B6D65204"><title>Use ROM-based
       
    92 bitmaps rather than filestore bitmaps</title><p>Uncompressed ROM-based bitmaps
       
    93 that can be used in place from ROM are approximately three times faster to
       
    94 use than filestore bitmaps. Using them can bring a significant reduction in
       
    95 application start-up time.</p><p>Specifying bitmap= instead of file= in the
       
    96 .OBY and .IBY files when building the ROM causes bitmaps to be uncompressed
       
    97 before inclusion in the ROM. Other bitmaps need to be uncompressed at runtime,
       
    98 which impacts performance.   </p><p>The drawback of such bitmaps is that they
       
    99 are large (up to 3 times larger than file based) and cannot be compressed,
       
   100 although decompressing bitmaps should probably be avoided during start-up
       
   101 anyway due to the extra processing required.   </p><p>If ROM space is limited,
       
   102 consider using such ROM-based bitmaps only if they are displayed during application
       
   103 start-up. </p></section>
       
   104 <section id="GUID-5FFD3311-DF8D-4EB1-9C76-EB9F3D306655"><title>Color depth
       
   105 matching</title><p>When bitmaps are drawn to the screen, optimum performance
       
   106 is achieved by ensuring that:</p><codeph>Bitmap color depth = Window color
       
   107 depth = Screen device color depth </codeph><p>If this is the case, no palette
       
   108 mapping between the different color depths is needed. On real hardware, this
       
   109 optimization has been found to improve drawing speed by up to ten times. However,
       
   110 in order to match the screen and window color depth, bitmaps may need to increase
       
   111 in size and so this optimization is only possible if the increase in ROM or
       
   112 RAM usage is acceptable. </p></section>
       
   113 <section id="GUID-5E89E812-4B22-4B5C-A5E4-5FBE6619DC25"><title>Minimize access
       
   114 to the file system</title><p>The file server can be a major bottleneck during
       
   115 start-up when virtually all threads are searching for and loading data, libraries
       
   116 and plug-ins. Therefore reducing file access is one of the most effective
       
   117 ways to improve performance. </p></section>
       
   118 <section id="GUID-9218ABF0-4062-439A-A5E9-273D76D4B711"><title>Minimize the
       
   119 use of resource files</title><p>Resource files are used for localization and
       
   120 allow modifications to be made to an application without the need to rebuild
       
   121 it, but they are expensive to use because they require access to the file
       
   122 system. </p></section>
       
   123 <section id="GUID-C1CCFD4F-5C63-47C4-A312-38ACB5C16676"><title>Do not specify
       
   124 a default document filename for non document-based applications</title><p>Many
       
   125 applications on a smartphone do not need to use documents, for example Telephony,
       
   126 Contacts (this uses the contacts database), Browser and Messaging.   </p><p>By
       
   127 not specifying a default document filename, hundreds of milliseconds can potentially
       
   128 be saved from such applications' start-up time.   </p><p>If an application
       
   129 uses a document file, application start-up may involve the following steps: </p><ul>
       
   130 <li><p>reading the name of the last used document file from the application’s
       
   131 .ini file,</p></li>
       
   132 <li><p>opening the document file, or if one doesn't exist, creating a default
       
   133 document file, after reading its name from the application's resource file, </p></li>
       
   134 <li><p>writing the name of the last used file to the application’s .ini file
       
   135 (which is created if it doesn’t exist),  </p></li>
       
   136 <li><p>writing an entry to the most recently used file list (mru.dat), </p></li>
       
   137 <li><p>additional document-related processing within <xref href="GUID-96CA3B4B-993F-36C0-9A5B-DF5CC74EE20E.dita#GUID-96CA3B4B-993F-36C0-9A5B-DF5CC74EE20E/GUID-E2A40307-6EB6-3ABC-B97A-63B77F565CCF"><apiname>CEikonEnv::ConstructAppFromCommandLineL()</apiname></xref>. </p></li>
       
   138 </ul><p>The default document's name is read from the application's resource
       
   139 file by <xref href="GUID-1185F595-0488-3E93-8D60-6B3A1A3AC32E.dita#GUID-1185F595-0488-3E93-8D60-6B3A1A3AC32E/GUID-5D851D0B-6399-3BD8-ADB5-63AD48494D47"><apiname>CEikAppUi::ProcessCommandParametersL()</apiname></xref>. There are
       
   140 two ways of preventing the application from using a default document file: </p><ul>
       
   141 <li><p>Give the default document a NULL name in the resource file:</p><codeph>RESOURCE
       
   142 TBUF { buf=""; }</codeph></li>
       
   143 <li><p>Override <xref href="GUID-1185F595-0488-3E93-8D60-6B3A1A3AC32E.dita#GUID-1185F595-0488-3E93-8D60-6B3A1A3AC32E/GUID-5D851D0B-6399-3BD8-ADB5-63AD48494D47"><apiname>CEikAppUi::ProcessCommandParametersL()</apiname></xref> to
       
   144 zero the document name and return EFalse. This method is slightly more efficient
       
   145 because it avoids reading the default document name from the resource file
       
   146 altogether: </p><codeblock xml:space="preserve">TBool CMyAppUi::ProcessCommandParametersL(TApaCommand /*aCommand*/, TFileName&amp; aDocumentName, const TDesC8&amp; /*aTail*/){aDocumentName.Zero();return EFalse;}</codeblock></li>
       
   147 </ul></section>
       
   148 <section id="GUID-2DF939E2-C30C-4A84-90DC-92234BEB6AA0"><title>Drive scanning</title><p>This
       
   149 can be a cause of unnecessary file server use.   </p><p>To prevent excessive
       
   150 drive access and scanning, always specify a drive letter in file paths, if
       
   151 known. The omission of a drive letter will cause all available drives to be
       
   152 searched in the standard Symbian platform order, in which Z: is always searched
       
   153 last. </p></section>
       
   154 <section id="GUID-C555545B-977F-490D-A7A7-5B6D0D0AD889"><title>Only make server
       
   155 requests if you need to</title><p> Server requests involve context switching
       
   156 and may cause the server to run instead of the application. In the worse case
       
   157 if you make a request to a server that has not yet been started you may cause
       
   158 the server to start. This will involve creating a new thread
       
   159 (and possibly process) and running any server initialization code.</p></section>
       
   160 <section id="GUID-1E571A30-5D8A-4647-939E-EF79B033B88E"><title>Use asynchronous
       
   161 server requests instead of synchronous server requests</title><p> Synchronous
       
   162 operations or methods (particularly for server requests) can cause general
       
   163 application slowness, and in particular, a significant reduction in responsiveness.
       
   164 Synchronous requests to servers mean your thread is waiting, so that no start-up
       
   165 progress is being made.   </p><p>No 'Golden Rule' exists about when to avoid
       
   166 synchronous requests. However, if an asynchronous version of a method exists,
       
   167 it is a good indication that the synchronous method could potentially take
       
   168 some time. Whilst it may take a little extra effort to handle asynchronous
       
   169 versions of method calls, you should consider very carefully any decision
       
   170 to use the synchronous version. It’s often easier to change from using an
       
   171 asynchronous version to synchronous than vice versa.   </p><p>Note that in
       
   172 some situations, you might know that the server is implementing your asynchronous
       
   173 request synchronously. If this is the case, and the server runs with a higher
       
   174 priority than your application, then both versions of the API may have the
       
   175 same performance. However, using the synchronous version in this case has
       
   176 the drawback that it relies upon knowledge of the server's implementation,
       
   177 which could potentially change. </p></section>
       
   178 <section id="GUID-4C7697BD-2898-4E1E-AA88-41E9F3CE2603"><title>Do not repeatedly
       
   179 open and close connections to the same server</title><p> Opening a connection
       
   180 to a server is an expensive operation. If an application uses a server frequently
       
   181 then it should create one connection and leave it open until the application
       
   182 is destroyed. R classes declared as temporaries (on the stack, in other words)
       
   183 within a method may be a sign of this behavior. </p></section>
       
   184 </conbody></concept>