--- a/Symbian3/PDK/Source/GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita Tue Jul 20 12:00:49 2010 +0100
+++ b/Symbian3/PDK/Source/GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita Fri Aug 13 16:47:46 2010 +0100
@@ -1,319 +1,319 @@
-<?xml version="1.0" encoding="utf-8"?>
-<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
-<!-- This component and the accompanying materials are made available under the terms of the License
-"Eclipse Public License v1.0" which accompanies this distribution,
-and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
-<!-- Initial Contributors:
- Nokia Corporation - initial contribution.
-Contributors:
--->
-<!DOCTYPE concept
- PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
-<concept id="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57" xml:lang="en"><title>Adjustable
-Performance Configuration</title><prolog><metadata><keywords/></metadata></prolog><conbody>
-<p>Various system parameters may be modified to control the way that elements
-within the system behave. The parameters listed in this document have been
-found to have significant impacts on important aspects of system performance. </p>
-<p>In each case there is trade off, typically between speed and resource use
-but sometimes between boot time and performance in steady state. The amount
-of trade off varies according hardware, software and how both are used. The
-only way of establishing the effect of each setting on a working device is
-through systematic testing. </p>
-<p>There is no common method of configuring the parameters listed here. Some
-of the values must be set before compilation, others before the ROM is built. </p>
-<ul>
-<li id="GUID-EE04CF03-F56D-52D7-BFF4-3D3AAB7C6106"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-09C25275-5D3A-514B-8F0D-C5C1A3FA41EC">Bitmaps</xref> </p> </li>
-<li id="GUID-02A6FF27-4E28-50F5-B0B7-C4BB20201FFE"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-6F89A67C-D05C-535B-B316-22EBECA7D7BF">Central Repository</xref> </p> </li>
-<li id="GUID-17BCAC94-0678-5048-A33F-151B36E0E83D"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-F0EB9A69-C00B-5778-AB90-E8C78CF0E2CB">Comms Server</xref> </p> </li>
-<li id="GUID-59149610-A605-5C6C-BA53-E921E2658D6C"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-4E07079A-B7B7-5020-BB15-8F31D5FAFCDA">Database Management System (DBMS)</xref> </p> </li>
-<li id="GUID-31BBAE9F-7427-5925-9FE7-907EC852C366"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-0E06EE19-F1FE-5940-8167-34654BFBA90A">Domain Name Daemon</xref> </p> </li>
-<li id="GUID-252ED29A-8F5A-54F2-A98C-65F48D080C61"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-BE38584C-7999-5D27-B4A2-1A7CFA82D311">Heap Configuration</xref> </p> </li>
-<li id="GUID-F6E88149-0B78-5E48-8399-51268803591F"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-9F765460-7F6A-5F2A-85DE-89EBFE213B1E">Recognizer Loading</xref> </p> </li>
-<li id="GUID-E5B09C3D-FF56-5D3B-B47A-B2D4EE265A86"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-9B98E4EB-28BC-5A0A-8174-7949E515AFA6">Secure Backup </xref> </p> </li>
-<li id="GUID-A49DD8FE-958E-542F-98EF-7926A2A10722"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-4EC82389-6C89-5C47-BAC4-A139BCB3531E">Server shutdown behaviour</xref> </p> </li>
-<li id="GUID-E792C035-38A4-561C-91CF-A23574E3E744"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-2CACB838-2E72-5723-9511-68EC1D7E3BDD">Window Server</xref> </p> </li>
-</ul>
-<section id="GUID-09C25275-5D3A-514B-8F0D-C5C1A3FA41EC"><title>Bitmaps</title> <p>Bitmaps
-use up large amounts of memory. There are several parameters that you can
-configure to reduce the amount of memory that bitmaps use. The effects that
-your adjustments have will depend upon both the nature of the bitmaps used
-in your system and the way that they are used. </p> <p><b>Bitmap compression ratio configuration </b> </p> <p>Bitmaps can be compressed
-using algorithms that typically take advantage of blocks of common colour.
-The amount that a bitmap can be compressed depends on the bitmap itself. </p> <p>A
-bitmap stored in a compressed format has to be decompressed before it can
-be displayed. </p> <p>A <b>compile-time macro</b>, <codeph>KCompressionThreshold</codeph>,
-specifies how much reduction in size must be achievable for bitmaps to be
-compressed. The theory is that if compression would only result in a small
-difference in size it is a waste of time. </p> <dl>
-<dlentry>
-<dt>Location</dt>
-<dd><p> <filepath>...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP</filepath> </p> </dd>
-</dlentry>
-<dlentry>
-<dt>Source</dt>
-<dd><codeblock id="GUID-BD267125-B08B-5723-9C4F-2737882BFD1D" xml:space="preserve">/*
-KCompressionThreshold is used to determine whether a bitmap gets compressed.
-Values of 0 -> 256 represent 0% to 100% where 0% = no compression.
-A value of 205 means that bitmaps are only compressed when the resulting size is 80% or less
-of the original size.
-*/
-MACRO KCompressionThreshold=205 // i.e. 80% compression
-</codeblock> </dd>
-</dlentry>
-</dl> <p>You must recompile FBServ for this change to take effect. </p> <p><b>Bitmap storage location </b> </p> <p>Bitmaps are stored in different memory
-locations according to their size. </p> <ul>
-<li id="GUID-08722693-3C5C-50FD-BD60-EBE2C3EC28A3"><p>Small bitmaps are stored
-in a normal heap called a shared chunk. </p> </li>
-<li id="GUID-9066CCC7-4872-5BEC-B754-3406E02CE234"><p>Large bitmaps are stored
-in special area of memory, called the large chunk or pile, that is managed
-by the font and bitmap server. </p> </li>
-</ul> <p>This is because storing and deleting bitmaps, especially large ones,
-leads to memory fragmentation which can prevent RAM being freed for the rest
-of the system. Defragmetation, however, is a slow process, so only the large
-chunk is defragmented. </p> <p>A <b>compile-time macro</b>, <codeph>KMaxLargeBitmapAlloc</codeph>,
-specifies the cut-off point (in kB) at which a bitmap is considered large
-and, therefore, stored in the large chunk. </p> <p>The higher the value the
-larger the bitmaps stored in the shared chunk will be. This typically results
-in higher RAM use, because the heap becomes more fragmented, but better overall
-system performance because the defragmentation process runs less often on
-the large chunk. </p> <dl>
-<dlentry>
-<dt>Location</dt>
-<dd><p> <filepath>...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP</filepath> </p> </dd>
-</dlentry>
-<dlentry>
-<dt>Source</dt>
-<dd><codeblock id="GUID-3EDA0707-66CD-563C-AB11-3FB72582CECB" xml:space="preserve">/*
-configurable value to control bitmap heap defragmentation by setting large bitmap threshold
-*/
-MACRO KMaxLargeBitmapAlloc=0x4000
-
-</codeblock> </dd>
-</dlentry>
-</dl> <p>You must recompile FBServ for this change to take effect. </p> <p><b>Large chunk defragmentation </b> </p> <p>Deleting large bitmaps results
-in fragmentation of the large chunk (see above). </p> <p>A <b>compile-time
-macro</b>, <codeph>KFreeCellCountLimit</codeph>, specifies the number of free
-cells that must exist in the large chunk before it gets defragmented. </p> <dl>
-<dlentry>
-<dt>Location</dt>
-<dd><p> <filepath>...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP</filepath> </p> </dd>
-</dlentry>
-<dlentry>
-<dt>Source</dt>
-<dd><codeblock id="GUID-576D18C1-6D4F-5E39-A69D-481D29F69CEE" xml:space="preserve">/*
-KFreeCellCountLimit determines when a forced foreground defragmentation will take place.
-This will happen during an allocation on the FBS large bitmap chunk if the amount
-of free cells exceeds the specified number.
-*/
-MACRO KFreeCellCountLimit=40
-</codeblock> </dd>
-</dlentry>
-</dl> <p>A smaller value will result in less wasted RAM but poorer performance
-as the defragmentation process will run more often. </p> <p> <b>NOTE:</b> Cells
-can be of variable size so this value cannot be used to calculate the amount
-of wasted RAM. You can be sure, however, that the wasted RAM will be at least
-(<codeph>KMaxLargeBitmapAlloc</codeph> x <codeph>KFreeCellCountLimit</codeph>).
-For the default values this is 160kB. </p> <p>You must recompile FBServ for
-this change to take effect. </p> <p><b>Using bitmap fonts </b> </p> <p>Using bitmap fonts instead of FreeType
-fonts can reduce RAM use and increase performance at the expense of visual
-appearance. FreeType fonts have to be rasterised before they can be used.
-This takes time and memory. Bitmap fonts, however, can only be used in the
-pre-determined range of sizes built into the ROM. </p> <p>The performance
-trade off is dependant on the font rasteriser though once a font has been
-rasterised it can be cached in bitmap form. </p> <p>NOTE: You can be pre-rasterise
-FreeType fonts into bitmap fonts for inclusion in ROMs using the <codeph>ttf2bdf</codeph> tool.
-Though the tool is supplied with the Symbian platform (as part of the <codeph>graphics_font</codeph> CBR
-component) it is not supported. There may also be legal and licencing issues
-to consider when pre-rasterising ronts in this way. </p> </section>
-<section id="GUID-6F89A67C-D05C-535B-B316-22EBECA7D7BF"><title>Central Repository </title> <p>The
-Central Repository caches individual repositories in RAM after clients have
-closed their sessions. You can configure the <i>sizeof the cache</i> and the <i>length
-of time that entries persist</i> by editing the central repository INI file <filepath>\private\10202be9\centrep.ini</filepath> </p> <codeblock id="GUID-D09B03B5-A74B-5EF5-B962-46756E491C48" xml:space="preserve">[CoarseGrainedCache]
-size= <size in bytes>
-timeout= <timeout in microseconds> </codeblock> <p>Increasing the size
-of the cache and the timeout improve performance at the cost of increased
-RAM use. </p> <p> <b>NOTE:</b> If the cache fills up the oldest entries are
-pushed out before they timeout. </p> </section>
-<section id="GUID-F0EB9A69-C00B-5778-AB90-E8C78CF0E2CB"><title>Comms Server</title> <p>You
-can adjust the size of the <codeph>MBuf</codeph> pool. The <codeph>MBuf</codeph> pool
-is used for creating buffers for communication data. </p> <p>The value is
-set in <filepath>...\os\commsfw\commsprocess\commsrootserverconfig\etc\c32start.ini</filepath>. </p> <codeblock id="GUID-77C0F002-8BA1-5D2E-9EC6-78098940D30D" xml:space="preserve">
-[Global]
-MBufPoolSize=<initial size in bytes>,<max size in bytes> //The default is MBufPoolSize=262144,262144. </codeblock> <p> <b>NOTE:</b> In
-older versions of the Symbian platform only the maximum size was specified
-so, for compatibility reasons, if a single value is specified it will be interpreted
-as the maximum size. </p> <p>When an initial size is specified the pool grows
-as necessary until it reaches the maximum size. It does not shrink, however,
-so the RAM is not released until the device is rebooted. The disadvantage
-of setting a very low initial pool size is that there might be insufficient
-free RAM pages when it tries to grow which could cause panics. </p> </section>
-<section id="GUID-4E07079A-B7B7-5020-BB15-8F31D5FAFCDA"><title>Database Management
-System (DBMS)</title> <p>The size of the <b>cache</b> used by DBMS and the
-size of the <b>buffer</b> used by STORE when performing disk I/O are adjustable.
-Reducing their sizes reduces memory use but results in more I/O operations
-which reduces performance. </p> <p>Adjust the sizes of the cache and buffer
-as follows: </p> <ol id="GUID-9021FD5C-01F7-575A-9B3B-DC7289266602">
-<li id="GUID-EA542EA4-975D-5075-AD6D-46E09B37CCBA"><p>Define the constants <codeph>SYMBIAN_CUSTOM_DBMS_CACHE_SIZES</codeph> and <codeph>SYMBIAN_CUSTOM_STORE_BUFFER_SIZES</codeph> in the appropriate HRH file in <filepath>\epoc32\include\variant</filepath>. </p> </li>
-<li id="GUID-2AA8EE9F-EDAD-515D-8407-8D4736A6CF15"><p>Create <filepath>...\os\persistentdata\persistentstorage\dbms\bmake\EDbms.mmh</filepath> by
-copying <filepath>...\os\persistentdata\persistentstorage\dbms\bmake\EDbms_Template.mmh</filepath>. </p> <p>Edit
-the newly created file and modify the following macros: </p> <ul>
-<li id="GUID-00DE06B9-95F2-5DCB-A63E-1586CAE2686E"><p> <codeph>PAGE_CACHE_SIZE</codeph> -
-the size of the page cache used to cache index information in a database.
-It must not be less than 8 pages. </p> </li>
-<li id="GUID-2182B6CC-F0CF-52F8-9986-231546A90D8C"><p> <codeph>MAX_CLUSTER_CACHE_SIZE</codeph> -
-the size of the cluster cache which is used to cache row data for tables in
-a database. It must not be less than 4 clusters. </p> </li>
-</ul> </li>
-<li id="GUID-E3FC7916-96B7-53F1-8E57-53243FFDAB78"><p>Create <filepath>...\os\persistentdata\persistentstorage\store\BMAKEEStor.mmh</filepath> by
-copying <filepath>...\os\persistentdata\persistentstorage\store\BMAKE\EStor_Template.mmh</filepath>. </p> <p>Edit
-the newly created file and modify the following macros: </p> <ul>
-<li id="GUID-5D98A6F3-160F-5348-B85D-97E387E8AE70"><p> <codeph>DEFAULT_FILE_BUF_SIZE</codeph> This
-macro sets the default file buffer size in bytes used in <xref href="GUID-418E7956-BE91-39A2-A26D-F1CA88B458AA.dita"><apiname>RFileBuf</apiname></xref> objects.
-It must not be less than 1536 bytes. </p> </li>
-<li id="GUID-A6CAC043-CC3E-519F-84DB-D1F9E6AB8C42"><p> <codeph>MAX_READ_AHEAD_VALUE</codeph> This
-macro sets the maximum <xref href="GUID-418E7956-BE91-39A2-A26D-F1CA88B458AA.dita"><apiname>RFileBuf</apiname></xref> read-ahead value in bytes.
-This defines the number of bytes read into the file buffer when buffer underflow
-occurs. It must not be less than 512 bytes or greater than <codeph>DEFAULT_FILE_BUF_SIZE</codeph> </p> </li>
-<li id="GUID-25FC3F98-0B4A-52E2-BF26-EDAEA0B03585"><p> <codeph>FILE_BLOCK_SIZE</codeph> This
-macro sets the file-system block size for <xref href="GUID-418E7956-BE91-39A2-A26D-F1CA88B458AA.dita"><apiname>RFileBuf</apiname></xref>. It
-is used in the event of a buffer underflow to perform block-aligned reads
-to load the buffer. It must not be less than 512 bytes or greater then <codeph>MAX_READ_AHEAD_VALUE</codeph>.
-It must also be a power of 2 </p> </li>
-</ul> </li>
-<li id="GUID-F7304DF3-99B5-50E5-8FA0-025A1C26317D"><p>Rebuild STORE then DBMS. </p> </li>
-</ol> </section>
-<section id="GUID-0E06EE19-F1FE-5940-8167-34654BFBA90A"><title>Domain Name
-Daemon</title> <p>You can control the number of concurrent requests handled
-by the Domain Name Daemon (DND). The DND reserves memory for these at startup
-to guarantee service. Reducing the number saves RAM but slows down web page
-retrieval, especially on pages with lots of in-line images. </p> <p>In the
-file <filepath>...\os\networkingsrv\tcpiputils\dnd\inc\listener.h</filepath> </p> <codeblock id="GUID-3DFE4664-CAC8-5FE0-8D25-00D14D8754B3" xml:space="preserve">const TUint KDndNumResolver = 31 ;</codeblock> <p>You
-can also limit the number of Link-Local Multicast Name Resolvers (LLNMR) that
-get created which also saves RAM but impacts performance because fewer concurrent
-DNS queries can be made </p> <p>In the file </p><filepath>...\os\networkingsrv\tcpiputils\dnd\inc\llmnrresponder.h</filepath> <codeblock id="GUID-E42FFFD4-2A9A-5D20-8171-F09AED1FEA15" xml:space="preserve">const TInt KLlmnrMaxEnabled = 15 ; </codeblock> <p> <b>NOTE:</b> You
-must ensure that there is at least one resolver enabled for each LLMNR-enabled
-network interface (NIF). </p> </section>
-<section id="GUID-BE38584C-7999-5D27-B4A2-1A7CFA82D311"><title>Heap Configuration</title> <p><b>Minimum heap cell size </b> </p> <p>You can set the minimum heap cell
-size used by the <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref> class. This has an impact on where
-new allocations are placed in the heap. You can set values for both the kernel
-heap and the user heap. </p> <p>The effect of changing the value is difficult
-to predict and there is not a simple relationship between size and RAM use
-or size and performance. In general, however, a larger value will result in
-faster performance and greater RAM use. </p> <p>Typical values to experiment
-with are 0, 4, 8, 16, 32 and 64. </p> <p>You set the value using a <codeph>patchdata</codeph> statement
-in an OBY (or IBY) file. </p> <codeblock id="GUID-76A70134-04D6-57B1-8F1D-7C7BF7813B3B" xml:space="preserve">
-patchdata [ekern.exe|euser.dll] @ KHeapMinCellSize <NewValueForTheConstData>
-</codeblock> <p>For example </p> <codeblock id="GUID-34B89B58-109B-5DFF-A91F-D1C50866CE54" xml:space="preserve">
-patchdata ekern.exe @ KHeapMinCellSize 32
-
-patchdata euser.dll @ KHeapMinCellSize 32
-</codeblock> <p><b>Hysteresis window size </b> </p> <p>You can configure how the memory allocated
-by the <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref> class is returned to the system. </p> <p>The
-heap grows in fixed size chunks. You can specify how quickly it shrinks (the
-amount of hysteresis) by setting <codeph>KHeapShrinkHysRatio</codeph>. </p> <p>The
-value of <codeph>KHeapShrinkHysRatio</codeph> is multiplied with the size
-of the growth chunk to establish the hysteresis value. When heap cells are
-freed the system waits until the number of free cells reaches the hysteresis
-value before releasing the memory. </p> <p>The default value of <codeph>KHeapShrinkHysRatio</codeph> is
-2.0. Reducing the value towards 1 frees memory more quickly. Values of 1 or
-less result in no hysteresis. More hysteresis results in faster performance,
-as heap allocations occur less often, but more RAM use. </p> <p>You set the
-value using a <codeph>patchdata</codeph> statement in an OBY (or IBY) file.
-For example, </p> <codeblock id="GUID-FE3EAA41-A9EE-5659-A57F-6186AE22BF65" xml:space="preserve">
-patchdata ekern.exe @ KHeapShrinkHysRatio 1.5
-
-patchdata euser.dll @ KHeapShrinkHysRatio 1.5
-</codeblock> </section>
-<section id="GUID-9F765460-7F6A-5F2A-85DE-89EBFE213B1E"><title>Recognizer
-Loading</title> <p>You can configure the Apparc server to load recognizer
-plugins at startup or on demand. Loading on demand reduces RAM consumption
-and boot time. The trade-off is that the first use of each recognizer takes
-longer to complete as it needs to be loaded before it can be used. Because
-recognizers typically get used several times in quick succession the impact
-of the trade off can be reduced by using a timer to defer unloading </p> <p>You
-can enable or disable load-on-demand and specify the delay before unloading
-using the <codeph>patchdata</codeph> statement in an OBY (or IBY) file. </p> <codeblock id="GUID-17741E7B-5EF8-52F9-9DED-C5482B78EDEE" xml:space="preserve">patchdata apserv.dll @ KApaLoadDataRecognizersOnDemand <newvalue> </codeblock> <p>The
-default <codeph>newvalue</codeph> is 0 which means that recognizers are loaded
-at boot. A value of 1 specifies that recognizers will be loaded on demand. </p> <codeblock id="GUID-D398EA48-F84C-528D-B0B1-40B8A8E6F1A1" xml:space="preserve">patchdata apserv.dll @ KApaUnloadRecognizersTimeout <newvalue> </codeblock> <p>The
-default<codeph>newvalue</codeph> is 10000000 (10 seconds in milliseconds). </p> </section>
-<section id="GUID-9B98E4EB-28BC-5A0A-8174-7949E515AFA6"><title>Secure Backup
-Optimisation</title> <p>The secure backup engine uses a shared chunk to communicate
-information efficiently between client and server components. You can set
-the size of the chunk, and other parameters, in a file called <filepath>sbeconfig.xml</filepath> in
-the private directory of the secure backup engine. The default size of the
-chunk is 2MB. </p> <codeblock id="GUID-08DAB844-88CF-560B-93E0-718CBEA0A9C4" xml:space="preserve">
-<?xml version="1.0" encoding="UTF-16" standalone="yes"?>
-<sbe_config>
- <heap size = "2097152" max_retries = "5" reduction_factor = "2"/>
- <central_repository uid = "0x10202BE9"/>
- <exclude_drives list = "z"/>
-</sbe_config>
- </codeblock> </section>
-<section id="GUID-4EC82389-6C89-5C47-BAC4-A139BCB3531E"><title> Server shutdown
-behaviour</title> <p>The shutdown behaviour of servers has a large impact
-on RAM and performance characteristics. If a server is always running it can
-respond faster to each request but requires RAM all the time. A transitive
-server is one which shuts down when it has no active connections. A transitive
-server uses RAM only when necessary but its performance will vary according
-to whether it needs to be started. </p> <p>You can configure the shutdown
-behaviour of several key Symbian servers. </p> <p><b>Message Server </b> </p> <p>Symbian provides two versions of the Message
-Server: an always-on version and a transitive one. You can select which one
-to include in your ROM by editing <filepath>../generic/messaging/framework/server/group/messageserver.iby</filepath> </p> <ul>
-<li id="GUID-563A829D-7ED3-50E0-A90C-472D2EBEA65C"><p>For always-on include <filepath>msgs.dll</filepath> in
-your ROM </p> </li>
-<li id="GUID-42CD2F3D-9552-5FC7-910E-3B8D6EE8892C"><p>For transitive behaviour
-include <filepath>msgs_autoshutdown.dll</filepath> in your ROM </p> </li>
-</ul> <p><b>Contacts Server </b> </p> <p>The behaviour of the Contacts Server is determined
-by a command line argument passed to <filepath>cntsrv.exe</filepath>. </p> <p>The
-default behaviour is transitive. For always-on behaviour you must start the
-server use the <codeph>-nontransient</codeph> option in your system startup
-file. </p> <codeblock id="GUID-85079652-9D30-5B44-BCDF-8DB41759B2CC" xml:space="preserve">
-START_PROCESS_INFO
- {
- path = "Z:\\sys\\bin\\cntsrv.exe";
- args = "-nontransient";
- ...
- }</codeblock> <p><b>Agenda Server </b> </p> <p>The behaviour of the Agenda Server is determined
-by a command line argument passed to <filepath>agsvexe.exe</filepath>. </p> <p>The
-default behaviour is transitive. For always-on behaviour you must start the
-server use the <codeph>-nontransient</codeph> option in your system startup
-file. </p> <codeblock id="GUID-DF1BBB3B-8A6E-5F63-B91C-9E4B9A952331" xml:space="preserve">
-START_PROCESS_INFO
- {
- path = "Z:\\sys\\bin\\agsvexe.exe";
- args = "-nontransient";
- ...
- }</codeblock> </section>
-<section id="GUID-2CACB838-2E72-5723-9511-68EC1D7E3BDD"><title>Window Server</title> <p><b>Flicker Free Redraw and Transparency </b> </p> <p>You can configure the
-drawing behaviour of the window server by enabling or disabling support for<b>flicker
-free redraw</b> and <b>transparency</b>. </p> <p>The window server is generally
-configured to allocate two full-screen bitmaps (which consume over 140kB each
-on a device with a normal resolution display). </p> <ul>
-<li id="GUID-E42668D2-7D67-527A-9A4A-A84A58781701"><p>An off-screen bitmap
-to reduce redraw flicker. Drawing commands between <codeph>BeginRedraw</codeph> and <codeph>EndRedraw</codeph> commands
-are committed to the off-screen bitmap. Only when <codeph>EndRedraw</codeph> is
-called does the window server update the screen with the contents of the off-screen
-bitmap. </p> </li>
-<li id="GUID-E4334927-57C3-5A1B-A6EF-549AFD203429"><p>A transparency bitmap
-to support transparent windows. </p> </li>
-</ul> <p>The allocation of these bitmaps can be configured in <filepath>Wsini.ini</filepath>. </p> <ul>
-<li id="GUID-B529F499-7FCC-5076-859C-3D0ABF8E0B9B"><p>The presence of the
-keyword <codeph>FLICKERFREEREDRAW</codeph> causes the off-screen bitmap to
-be allocated. </p> </li>
-<li id="GUID-751FB913-C942-5F8D-9A36-0B2727941977"><p>The presence of the
-keyword <codeph>TRANSPARENCY</codeph> causes <b>both</b> the off-screen and
-transparency bitmaps to be allocated. </p> </li>
-<li id="GUID-7D32B174-8E33-5292-9096-3EF0EB825C60"><p>If neither keyword is
-present no full-screen bitmaps are allocated. </p> </li>
-</ul> <p> </p> <p>In practice flicker free redraw makes a noticeable improvement
-to most UIs. If a UI uses transparent windows both bitmaps must be enabled. </p> <p><b>The default window server command buffer </b> </p> <p>Each connection
-to the window server has a command buffer so that the number of inter-process
-calls can be reduced. The buffer has a default size (<codeph>EClientBufferSize</codeph>)
-which is typically the minimum of 640 bytes. Applications can override the
-default whenever they create an <codeph>RWsSession</codeph>. </p> <p>The default
-buffer size is defined in <filepath>...\os\graphics\windowing\windowserver\SERVER\w32cmd.h</filepath> </p> <p>The
-benefit of a small buffer is reduced RAM use. The benefits of a bigger buffer
-are reduced IPC (so drawing is more efficient) and reduced flicker. </p> <p> <b>NOTE:</b> Increasing
-the buffer size to reduce flicker is less effective than using the <codeph>FICKERFREEREDRAW</codeph> feature
-described above. </p> </section>
+<?xml version="1.0" encoding="utf-8"?>
+<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
+<!-- This component and the accompanying materials are made available under the terms of the License
+"Eclipse Public License v1.0" which accompanies this distribution,
+and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
+<!-- Initial Contributors:
+ Nokia Corporation - initial contribution.
+Contributors:
+-->
+<!DOCTYPE concept
+ PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
+<concept id="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57" xml:lang="en"><title>Adjustable
+Performance Configuration</title><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>Various system parameters may be modified to control the way that elements
+within the system behave. The parameters listed in this document have been
+found to have significant impacts on important aspects of system performance. </p>
+<p>In each case there is trade off, typically between speed and resource use
+but sometimes between boot time and performance in steady state. The amount
+of trade off varies according hardware, software and how both are used. The
+only way of establishing the effect of each setting on a working device is
+through systematic testing. </p>
+<p>There is no common method of configuring the parameters listed here. Some
+of the values must be set before compilation, others before the ROM is built. </p>
+<ul>
+<li id="GUID-EE04CF03-F56D-52D7-BFF4-3D3AAB7C6106"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-09C25275-5D3A-514B-8F0D-C5C1A3FA41EC">Bitmaps</xref> </p> </li>
+<li id="GUID-02A6FF27-4E28-50F5-B0B7-C4BB20201FFE"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-6F89A67C-D05C-535B-B316-22EBECA7D7BF">Central Repository</xref> </p> </li>
+<li id="GUID-17BCAC94-0678-5048-A33F-151B36E0E83D"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-F0EB9A69-C00B-5778-AB90-E8C78CF0E2CB">Comms Server</xref> </p> </li>
+<li id="GUID-59149610-A605-5C6C-BA53-E921E2658D6C"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-4E07079A-B7B7-5020-BB15-8F31D5FAFCDA">Database Management System (DBMS)</xref> </p> </li>
+<li id="GUID-31BBAE9F-7427-5925-9FE7-907EC852C366"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-0E06EE19-F1FE-5940-8167-34654BFBA90A">Domain Name Daemon</xref> </p> </li>
+<li id="GUID-252ED29A-8F5A-54F2-A98C-65F48D080C61"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-BE38584C-7999-5D27-B4A2-1A7CFA82D311">Heap Configuration</xref> </p> </li>
+<li id="GUID-F6E88149-0B78-5E48-8399-51268803591F"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-9F765460-7F6A-5F2A-85DE-89EBFE213B1E">Recognizer Loading</xref> </p> </li>
+<li id="GUID-E5B09C3D-FF56-5D3B-B47A-B2D4EE265A86"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-9B98E4EB-28BC-5A0A-8174-7949E515AFA6">Secure Backup </xref> </p> </li>
+<li id="GUID-A49DD8FE-958E-542F-98EF-7926A2A10722"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-4EC82389-6C89-5C47-BAC4-A139BCB3531E">Server shutdown behaviour</xref> </p> </li>
+<li id="GUID-E792C035-38A4-561C-91CF-A23574E3E744"><p><xref href="GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57.dita#GUID-7E401451-16EB-515B-88B2-4D0D2D6C7A57/GUID-2CACB838-2E72-5723-9511-68EC1D7E3BDD">Window Server</xref> </p> </li>
+</ul>
+<section id="GUID-09C25275-5D3A-514B-8F0D-C5C1A3FA41EC"><title>Bitmaps</title> <p>Bitmaps
+use up large amounts of memory. There are several parameters that you can
+configure to reduce the amount of memory that bitmaps use. The effects that
+your adjustments have will depend upon both the nature of the bitmaps used
+in your system and the way that they are used. </p> <p><b>Bitmap compression ratio configuration </b> </p> <p>Bitmaps can be compressed
+using algorithms that typically take advantage of blocks of common colour.
+The amount that a bitmap can be compressed depends on the bitmap itself. </p> <p>A
+bitmap stored in a compressed format has to be decompressed before it can
+be displayed. </p> <p>A <b>compile-time macro</b>, <codeph>KCompressionThreshold</codeph>,
+specifies how much reduction in size must be achievable for bitmaps to be
+compressed. The theory is that if compression would only result in a small
+difference in size it is a waste of time. </p> <dl>
+<dlentry>
+<dt>Location</dt>
+<dd><p> <filepath>...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP</filepath> </p> </dd>
+</dlentry>
+<dlentry>
+<dt>Source</dt>
+<dd><codeblock id="GUID-BD267125-B08B-5723-9C4F-2737882BFD1D" xml:space="preserve">/*
+KCompressionThreshold is used to determine whether a bitmap gets compressed.
+Values of 0 -> 256 represent 0% to 100% where 0% = no compression.
+A value of 205 means that bitmaps are only compressed when the resulting size is 80% or less
+of the original size.
+*/
+MACRO KCompressionThreshold=205 // i.e. 80% compression
+</codeblock> </dd>
+</dlentry>
+</dl> <p>You must recompile FBServ for this change to take effect. </p> <p><b>Bitmap storage location </b> </p> <p>Bitmaps are stored in different memory
+locations according to their size. </p> <ul>
+<li id="GUID-08722693-3C5C-50FD-BD60-EBE2C3EC28A3"><p>Small bitmaps are stored
+in a normal heap called a shared chunk. </p> </li>
+<li id="GUID-9066CCC7-4872-5BEC-B754-3406E02CE234"><p>Large bitmaps are stored
+in special area of memory, called the large chunk or pile, that is managed
+by the font and bitmap server. </p> </li>
+</ul> <p>This is because storing and deleting bitmaps, especially large ones,
+leads to memory fragmentation which can prevent RAM being freed for the rest
+of the system. Defragmetation, however, is a slow process, so only the large
+chunk is defragmented. </p> <p>A <b>compile-time macro</b>, <codeph>KMaxLargeBitmapAlloc</codeph>,
+specifies the cut-off point (in kB) at which a bitmap is considered large
+and, therefore, stored in the large chunk. </p> <p>The higher the value the
+larger the bitmaps stored in the shared chunk will be. This typically results
+in higher RAM use, because the heap becomes more fragmented, but better overall
+system performance because the defragmentation process runs less often on
+the large chunk. </p> <dl>
+<dlentry>
+<dt>Location</dt>
+<dd><p> <filepath>...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP</filepath> </p> </dd>
+</dlentry>
+<dlentry>
+<dt>Source</dt>
+<dd><codeblock id="GUID-3EDA0707-66CD-563C-AB11-3FB72582CECB" xml:space="preserve">/*
+configurable value to control bitmap heap defragmentation by setting large bitmap threshold
+*/
+MACRO KMaxLargeBitmapAlloc=0x4000
+
+</codeblock> </dd>
+</dlentry>
+</dl> <p>You must recompile FBServ for this change to take effect. </p> <p><b>Large chunk defragmentation </b> </p> <p>Deleting large bitmaps results
+in fragmentation of the large chunk (see above). </p> <p>A <b>compile-time
+macro</b>, <codeph>KFreeCellCountLimit</codeph>, specifies the number of free
+cells that must exist in the large chunk before it gets defragmented. </p> <dl>
+<dlentry>
+<dt>Location</dt>
+<dd><p> <filepath>...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP</filepath> </p> </dd>
+</dlentry>
+<dlentry>
+<dt>Source</dt>
+<dd><codeblock id="GUID-576D18C1-6D4F-5E39-A69D-481D29F69CEE" xml:space="preserve">/*
+KFreeCellCountLimit determines when a forced foreground defragmentation will take place.
+This will happen during an allocation on the FBS large bitmap chunk if the amount
+of free cells exceeds the specified number.
+*/
+MACRO KFreeCellCountLimit=40
+</codeblock> </dd>
+</dlentry>
+</dl> <p>A smaller value will result in less wasted RAM but poorer performance
+as the defragmentation process will run more often. </p> <p> <b>NOTE:</b> Cells
+can be of variable size so this value cannot be used to calculate the amount
+of wasted RAM. You can be sure, however, that the wasted RAM will be at least
+(<codeph>KMaxLargeBitmapAlloc</codeph> x <codeph>KFreeCellCountLimit</codeph>).
+For the default values this is 160kB. </p> <p>You must recompile FBServ for
+this change to take effect. </p> <p><b>Using bitmap fonts </b> </p> <p>Using bitmap fonts instead of FreeType
+fonts can reduce RAM use and increase performance at the expense of visual
+appearance. FreeType fonts have to be rasterised before they can be used.
+This takes time and memory. Bitmap fonts, however, can only be used in the
+pre-determined range of sizes built into the ROM. </p> <p>The performance
+trade off is dependant on the font rasteriser though once a font has been
+rasterised it can be cached in bitmap form. </p> <p>NOTE: You can be pre-rasterise
+FreeType fonts into bitmap fonts for inclusion in ROMs using the <codeph>ttf2bdf</codeph> tool.
+Though the tool is supplied with the Symbian platform (as part of the <codeph>graphics_font</codeph> CBR
+component) it is not supported. There may also be legal and licencing issues
+to consider when pre-rasterising ronts in this way. </p> </section>
+<section id="GUID-6F89A67C-D05C-535B-B316-22EBECA7D7BF"><title>Central Repository </title> <p>The
+Central Repository caches individual repositories in RAM after clients have
+closed their sessions. You can configure the <i>sizeof the cache</i> and the <i>length
+of time that entries persist</i> by editing the central repository INI file <filepath>\private\10202be9\centrep.ini</filepath> </p> <codeblock id="GUID-D09B03B5-A74B-5EF5-B962-46756E491C48" xml:space="preserve">[CoarseGrainedCache]
+size= <size in bytes>
+timeout= <timeout in microseconds> </codeblock> <p>Increasing the size
+of the cache and the timeout improve performance at the cost of increased
+RAM use. </p> <p> <b>NOTE:</b> If the cache fills up the oldest entries are
+pushed out before they timeout. </p> </section>
+<section id="GUID-F0EB9A69-C00B-5778-AB90-E8C78CF0E2CB"><title>Comms Server</title> <p>You
+can adjust the size of the <codeph>MBuf</codeph> pool. The <codeph>MBuf</codeph> pool
+is used for creating buffers for communication data. </p> <p>The value is
+set in <filepath>...\os\commsfw\commsprocess\commsrootserverconfig\etc\c32start.ini</filepath>. </p> <codeblock id="GUID-77C0F002-8BA1-5D2E-9EC6-78098940D30D" xml:space="preserve">
+[Global]
+MBufPoolSize=<initial size in bytes>,<max size in bytes> //The default is MBufPoolSize=262144,262144. </codeblock> <p> <b>NOTE:</b> In
+older versions of the Symbian platform only the maximum size was specified
+so, for compatibility reasons, if a single value is specified it will be interpreted
+as the maximum size. </p> <p>When an initial size is specified the pool grows
+as necessary until it reaches the maximum size. It does not shrink, however,
+so the RAM is not released until the device is rebooted. The disadvantage
+of setting a very low initial pool size is that there might be insufficient
+free RAM pages when it tries to grow which could cause panics. </p> </section>
+<section id="GUID-4E07079A-B7B7-5020-BB15-8F31D5FAFCDA"><title>Database Management
+System (DBMS)</title> <p>The size of the <b>cache</b> used by DBMS and the
+size of the <b>buffer</b> used by STORE when performing disk I/O are adjustable.
+Reducing their sizes reduces memory use but results in more I/O operations
+which reduces performance. </p> <p>Adjust the sizes of the cache and buffer
+as follows: </p> <ol id="GUID-9021FD5C-01F7-575A-9B3B-DC7289266602">
+<li id="GUID-EA542EA4-975D-5075-AD6D-46E09B37CCBA"><p>Define the constants <codeph>SYMBIAN_CUSTOM_DBMS_CACHE_SIZES</codeph> and <codeph>SYMBIAN_CUSTOM_STORE_BUFFER_SIZES</codeph> in the appropriate HRH file in <filepath>\epoc32\include\variant</filepath>. </p> </li>
+<li id="GUID-2AA8EE9F-EDAD-515D-8407-8D4736A6CF15"><p>Create <filepath>...\os\persistentdata\persistentstorage\dbms\bmake\EDbms.mmh</filepath> by
+copying <filepath>...\os\persistentdata\persistentstorage\dbms\bmake\EDbms_Template.mmh</filepath>. </p> <p>Edit
+the newly created file and modify the following macros: </p> <ul>
+<li id="GUID-00DE06B9-95F2-5DCB-A63E-1586CAE2686E"><p> <codeph>PAGE_CACHE_SIZE</codeph> -
+the size of the page cache used to cache index information in a database.
+It must not be less than 8 pages. </p> </li>
+<li id="GUID-2182B6CC-F0CF-52F8-9986-231546A90D8C"><p> <codeph>MAX_CLUSTER_CACHE_SIZE</codeph> -
+the size of the cluster cache which is used to cache row data for tables in
+a database. It must not be less than 4 clusters. </p> </li>
+</ul> </li>
+<li id="GUID-E3FC7916-96B7-53F1-8E57-53243FFDAB78"><p>Create <filepath>...\os\persistentdata\persistentstorage\store\BMAKEEStor.mmh</filepath> by
+copying <filepath>...\os\persistentdata\persistentstorage\store\BMAKE\EStor_Template.mmh</filepath>. </p> <p>Edit
+the newly created file and modify the following macros: </p> <ul>
+<li id="GUID-5D98A6F3-160F-5348-B85D-97E387E8AE70"><p> <codeph>DEFAULT_FILE_BUF_SIZE</codeph> This
+macro sets the default file buffer size in bytes used in <xref href="GUID-418E7956-BE91-39A2-A26D-F1CA88B458AA.dita"><apiname>RFileBuf</apiname></xref> objects.
+It must not be less than 1536 bytes. </p> </li>
+<li id="GUID-A6CAC043-CC3E-519F-84DB-D1F9E6AB8C42"><p> <codeph>MAX_READ_AHEAD_VALUE</codeph> This
+macro sets the maximum <xref href="GUID-418E7956-BE91-39A2-A26D-F1CA88B458AA.dita"><apiname>RFileBuf</apiname></xref> read-ahead value in bytes.
+This defines the number of bytes read into the file buffer when buffer underflow
+occurs. It must not be less than 512 bytes or greater than <codeph>DEFAULT_FILE_BUF_SIZE</codeph> </p> </li>
+<li id="GUID-25FC3F98-0B4A-52E2-BF26-EDAEA0B03585"><p> <codeph>FILE_BLOCK_SIZE</codeph> This
+macro sets the file-system block size for <xref href="GUID-418E7956-BE91-39A2-A26D-F1CA88B458AA.dita"><apiname>RFileBuf</apiname></xref>. It
+is used in the event of a buffer underflow to perform block-aligned reads
+to load the buffer. It must not be less than 512 bytes or greater then <codeph>MAX_READ_AHEAD_VALUE</codeph>.
+It must also be a power of 2 </p> </li>
+</ul> </li>
+<li id="GUID-F7304DF3-99B5-50E5-8FA0-025A1C26317D"><p>Rebuild STORE then DBMS. </p> </li>
+</ol> </section>
+<section id="GUID-0E06EE19-F1FE-5940-8167-34654BFBA90A"><title>Domain Name
+Daemon</title> <p>You can control the number of concurrent requests handled
+by the Domain Name Daemon (DND). The DND reserves memory for these at startup
+to guarantee service. Reducing the number saves RAM but slows down web page
+retrieval, especially on pages with lots of in-line images. </p> <p>In the
+file <filepath>...\os\networkingsrv\tcpiputils\dnd\inc\listener.h</filepath> </p> <codeblock id="GUID-3DFE4664-CAC8-5FE0-8D25-00D14D8754B3" xml:space="preserve">const TUint KDndNumResolver = 31 ;</codeblock> <p>You
+can also limit the number of Link-Local Multicast Name Resolvers (LLNMR) that
+get created which also saves RAM but impacts performance because fewer concurrent
+DNS queries can be made </p> <p>In the file </p><filepath>...\os\networkingsrv\tcpiputils\dnd\inc\llmnrresponder.h</filepath> <codeblock id="GUID-E42FFFD4-2A9A-5D20-8171-F09AED1FEA15" xml:space="preserve">const TInt KLlmnrMaxEnabled = 15 ; </codeblock> <p> <b>NOTE:</b> You
+must ensure that there is at least one resolver enabled for each LLMNR-enabled
+network interface (NIF). </p> </section>
+<section id="GUID-BE38584C-7999-5D27-B4A2-1A7CFA82D311"><title>Heap Configuration</title> <p><b>Minimum heap cell size </b> </p> <p>You can set the minimum heap cell
+size used by the <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref> class. This has an impact on where
+new allocations are placed in the heap. You can set values for both the kernel
+heap and the user heap. </p> <p>The effect of changing the value is difficult
+to predict and there is not a simple relationship between size and RAM use
+or size and performance. In general, however, a larger value will result in
+faster performance and greater RAM use. </p> <p>Typical values to experiment
+with are 0, 4, 8, 16, 32 and 64. </p> <p>You set the value using a <codeph>patchdata</codeph> statement
+in an OBY (or IBY) file. </p> <codeblock id="GUID-76A70134-04D6-57B1-8F1D-7C7BF7813B3B" xml:space="preserve">
+patchdata [ekern.exe|euser.dll] @ KHeapMinCellSize <NewValueForTheConstData>
+</codeblock> <p>For example </p> <codeblock id="GUID-34B89B58-109B-5DFF-A91F-D1C50866CE54" xml:space="preserve">
+patchdata ekern.exe @ KHeapMinCellSize 32
+
+patchdata euser.dll @ KHeapMinCellSize 32
+</codeblock> <p><b>Hysteresis window size </b> </p> <p>You can configure how the memory allocated
+by the <xref href="GUID-EFAFDD75-7E59-306A-882D-317F5564979E.dita"><apiname>RHeap</apiname></xref> class is returned to the system. </p> <p>The
+heap grows in fixed size chunks. You can specify how quickly it shrinks (the
+amount of hysteresis) by setting <codeph>KHeapShrinkHysRatio</codeph>. </p> <p>The
+value of <codeph>KHeapShrinkHysRatio</codeph> is multiplied with the size
+of the growth chunk to establish the hysteresis value. When heap cells are
+freed the system waits until the number of free cells reaches the hysteresis
+value before releasing the memory. </p> <p>The default value of <codeph>KHeapShrinkHysRatio</codeph> is
+2.0. Reducing the value towards 1 frees memory more quickly. Values of 1 or
+less result in no hysteresis. More hysteresis results in faster performance,
+as heap allocations occur less often, but more RAM use. </p> <p>You set the
+value using a <codeph>patchdata</codeph> statement in an OBY (or IBY) file.
+For example, </p> <codeblock id="GUID-FE3EAA41-A9EE-5659-A57F-6186AE22BF65" xml:space="preserve">
+patchdata ekern.exe @ KHeapShrinkHysRatio 1.5
+
+patchdata euser.dll @ KHeapShrinkHysRatio 1.5
+</codeblock> </section>
+<section id="GUID-9F765460-7F6A-5F2A-85DE-89EBFE213B1E"><title>Recognizer
+Loading</title> <p>You can configure the Apparc server to load recognizer
+plugins at startup or on demand. Loading on demand reduces RAM consumption
+and boot time. The trade-off is that the first use of each recognizer takes
+longer to complete as it needs to be loaded before it can be used. Because
+recognizers typically get used several times in quick succession the impact
+of the trade off can be reduced by using a timer to defer unloading </p> <p>You
+can enable or disable load-on-demand and specify the delay before unloading
+using the <codeph>patchdata</codeph> statement in an OBY (or IBY) file. </p> <codeblock id="GUID-17741E7B-5EF8-52F9-9DED-C5482B78EDEE" xml:space="preserve">patchdata apserv.dll @ KApaLoadDataRecognizersOnDemand <newvalue> </codeblock> <p>The
+default <codeph>newvalue</codeph> is 0 which means that recognizers are loaded
+at boot. A value of 1 specifies that recognizers will be loaded on demand. </p> <codeblock id="GUID-D398EA48-F84C-528D-B0B1-40B8A8E6F1A1" xml:space="preserve">patchdata apserv.dll @ KApaUnloadRecognizersTimeout <newvalue> </codeblock> <p>The
+default<codeph>newvalue</codeph> is 10000000 (10 seconds in milliseconds). </p> </section>
+<section id="GUID-9B98E4EB-28BC-5A0A-8174-7949E515AFA6"><title>Secure Backup
+Optimisation</title> <p>The secure backup engine uses a shared chunk to communicate
+information efficiently between client and server components. You can set
+the size of the chunk, and other parameters, in a file called <filepath>sbeconfig.xml</filepath> in
+the private directory of the secure backup engine. The default size of the
+chunk is 2MB. </p> <codeblock id="GUID-08DAB844-88CF-560B-93E0-718CBEA0A9C4" xml:space="preserve">
+<?xml version="1.0" encoding="UTF-16" standalone="yes"?>
+<sbe_config>
+ <heap size = "2097152" max_retries = "5" reduction_factor = "2"/>
+ <central_repository uid = "0x10202BE9"/>
+ <exclude_drives list = "z"/>
+</sbe_config>
+ </codeblock> </section>
+<section id="GUID-4EC82389-6C89-5C47-BAC4-A139BCB3531E"><title> Server shutdown
+behaviour</title> <p>The shutdown behaviour of servers has a large impact
+on RAM and performance characteristics. If a server is always running it can
+respond faster to each request but requires RAM all the time. A transitive
+server is one which shuts down when it has no active connections. A transitive
+server uses RAM only when necessary but its performance will vary according
+to whether it needs to be started. </p> <p>You can configure the shutdown
+behaviour of several key Symbian servers. </p> <p><b>Message Server </b> </p> <p>Symbian provides two versions of the Message
+Server: an always-on version and a transitive one. You can select which one
+to include in your ROM by editing <filepath>../generic/messaging/framework/server/group/messageserver.iby</filepath> </p> <ul>
+<li id="GUID-563A829D-7ED3-50E0-A90C-472D2EBEA65C"><p>For always-on include <filepath>msgs.dll</filepath> in
+your ROM </p> </li>
+<li id="GUID-42CD2F3D-9552-5FC7-910E-3B8D6EE8892C"><p>For transitive behaviour
+include <filepath>msgs_autoshutdown.dll</filepath> in your ROM </p> </li>
+</ul> <p><b>Contacts Server </b> </p> <p>The behaviour of the Contacts Server is determined
+by a command line argument passed to <filepath>cntsrv.exe</filepath>. </p> <p>The
+default behaviour is transitive. For always-on behaviour you must start the
+server use the <codeph>-nontransient</codeph> option in your system startup
+file. </p> <codeblock id="GUID-85079652-9D30-5B44-BCDF-8DB41759B2CC" xml:space="preserve">
+START_PROCESS_INFO
+ {
+ path = "Z:\\sys\\bin\\cntsrv.exe";
+ args = "-nontransient";
+ ...
+ }</codeblock> <p><b>Agenda Server </b> </p> <p>The behaviour of the Agenda Server is determined
+by a command line argument passed to <filepath>agsvexe.exe</filepath>. </p> <p>The
+default behaviour is transitive. For always-on behaviour you must start the
+server use the <codeph>-nontransient</codeph> option in your system startup
+file. </p> <codeblock id="GUID-DF1BBB3B-8A6E-5F63-B91C-9E4B9A952331" xml:space="preserve">
+START_PROCESS_INFO
+ {
+ path = "Z:\\sys\\bin\\agsvexe.exe";
+ args = "-nontransient";
+ ...
+ }</codeblock> </section>
+<section id="GUID-2CACB838-2E72-5723-9511-68EC1D7E3BDD"><title>Window Server</title> <p><b>Flicker Free Redraw and Transparency </b> </p> <p>You can configure the
+drawing behaviour of the window server by enabling or disabling support for<b>flicker
+free redraw</b> and <b>transparency</b>. </p> <p>The window server is generally
+configured to allocate two full-screen bitmaps (which consume over 140kB each
+on a device with a normal resolution display). </p> <ul>
+<li id="GUID-E42668D2-7D67-527A-9A4A-A84A58781701"><p>An off-screen bitmap
+to reduce redraw flicker. Drawing commands between <codeph>BeginRedraw</codeph> and <codeph>EndRedraw</codeph> commands
+are committed to the off-screen bitmap. Only when <codeph>EndRedraw</codeph> is
+called does the window server update the screen with the contents of the off-screen
+bitmap. </p> </li>
+<li id="GUID-E4334927-57C3-5A1B-A6EF-549AFD203429"><p>A transparency bitmap
+to support transparent windows. </p> </li>
+</ul> <p>The allocation of these bitmaps can be configured in <filepath>Wsini.ini</filepath>. </p> <ul>
+<li id="GUID-B529F499-7FCC-5076-859C-3D0ABF8E0B9B"><p>The presence of the
+keyword <codeph>FLICKERFREEREDRAW</codeph> causes the off-screen bitmap to
+be allocated. </p> </li>
+<li id="GUID-751FB913-C942-5F8D-9A36-0B2727941977"><p>The presence of the
+keyword <codeph>TRANSPARENCY</codeph> causes <b>both</b> the off-screen and
+transparency bitmaps to be allocated. </p> </li>
+<li id="GUID-7D32B174-8E33-5292-9096-3EF0EB825C60"><p>If neither keyword is
+present no full-screen bitmaps are allocated. </p> </li>
+</ul> <p> </p> <p>In practice flicker free redraw makes a noticeable improvement
+to most UIs. If a UI uses transparent windows both bitmaps must be enabled. </p> <p><b>The default window server command buffer </b> </p> <p>Each connection
+to the window server has a command buffer so that the number of inter-process
+calls can be reduced. The buffer has a default size (<codeph>EClientBufferSize</codeph>)
+which is typically the minimum of 640 bytes. Applications can override the
+default whenever they create an <codeph>RWsSession</codeph>. </p> <p>The default
+buffer size is defined in <filepath>...\os\graphics\windowing\windowserver\SERVER\w32cmd.h</filepath> </p> <p>The
+benefit of a small buffer is reduced RAM use. The benefits of a bigger buffer
+are reduced IPC (so drawing is more efficient) and reduced flicker. </p> <p> <b>NOTE:</b> Increasing
+the buffer size to reduce flicker is less effective than using the <codeph>FICKERFREEREDRAW</codeph> feature
+described above. </p> </section>
</conbody></concept>
\ No newline at end of file