Adjustable -Performance Configuration

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.

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.

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.

Bitmaps
Central Repository
Comms Server
Database Management System (DBMS)
Domain Name Daemon
Heap Configuration
Recognizer Loading
Secure Backup
Server shutdown behaviour
Window Server

Bitmaps

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.

Bitmap compression ratio configuration

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.

A -bitmap stored in a compressed format has to be decompressed before it can -be displayed.

A compile-time macro, KCompressionThreshold, -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.

Location: ...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP
Source: /* -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 -

You must recompile FBServ for this change to take effect.

Bitmap storage location

Bitmaps are stored in different memory -locations according to their size.

Small bitmaps are stored -in a normal heap called a shared chunk.
Large bitmaps are stored -in special area of memory, called the large chunk or pile, that is managed -by the font and bitmap server.

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.

A compile-time macro, KMaxLargeBitmapAlloc, -specifies the cut-off point (in kB) at which a bitmap is considered large -and, therefore, stored in the large chunk.

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.

Location: ...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP
Source: /* -configurable value to control bitmap heap defragmentation by setting large bitmap threshold -*/ -MACRO KMaxLargeBitmapAlloc=0x4000 - -

You must recompile FBServ for this change to take effect.

Large chunk defragmentation

Deleting large bitmaps results -in fragmentation of the large chunk (see above).

A compile-time -macro, KFreeCellCountLimit, specifies the number of free -cells that must exist in the large chunk before it gets defragmented.

Location: ...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP
Source: /* -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 -

A smaller value will result in less wasted RAM but poorer performance -as the defragmentation process will run more often.

NOTE: 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 -(KMaxLargeBitmapAlloc x KFreeCellCountLimit). -For the default values this is 160kB.

You must recompile FBServ for -this change to take effect.

Using bitmap fonts

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.

The performance -trade off is dependant on the font rasteriser though once a font has been -rasterised it can be cached in bitmap form.

NOTE: You can be pre-rasterise -FreeType fonts into bitmap fonts for inclusion in ROMs using the ttf2bdf tool. -Though the tool is supplied with the Symbian platform (as part of the graphics_font CBR -component) it is not supported. There may also be legal and licencing issues -to consider when pre-rasterising ronts in this way.

Central Repository

The -Central Repository caches individual repositories in RAM after clients have -closed their sessions. You can configure the sizeof the cache and the length -of time that entries persist by editing the central repository INI file \private\10202be9\centrep.ini

[CoarseGrainedCache] -size= <size in bytes> -timeout= <timeout in microseconds>

Increasing the size -of the cache and the timeout improve performance at the cost of increased -RAM use.

NOTE: If the cache fills up the oldest entries are -pushed out before they timeout.

Comms Server

You -can adjust the size of the MBuf pool. The MBuf pool -is used for creating buffers for communication data.

The value is -set in ...\os\commsfw\commsprocess\commsrootserverconfig\etc\c32start.ini.

-[Global] -MBufPoolSize=<initial size in bytes>,<max size in bytes> //The default is MBufPoolSize=262144,262144.

NOTE: 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.

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.

Database Management -System (DBMS)

The size of the cache used by DBMS and the -size of the buffer 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.

Adjust the sizes of the cache and buffer -as follows:

Define the constants SYMBIAN_CUSTOM_DBMS_CACHE_SIZES and SYMBIAN_CUSTOM_STORE_BUFFER_SIZES in the appropriate HRH file in \epoc32\include\variant.
Create ...\os\persistentdata\persistentstorage\dbms\bmake\EDbms.mmh by -copying ...\os\persistentdata\persistentstorage\dbms\bmake\EDbms_Template.mmh.

Edit -the newly created file and modify the following macros:
- PAGE_CACHE_SIZE - -the size of the page cache used to cache index information in a database. -It must not be less than 8 pages.
- MAX_CLUSTER_CACHE_SIZE - -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.
Create ...\os\persistentdata\persistentstorage\store\BMAKEEStor.mmh by -copying ...\os\persistentdata\persistentstorage\store\BMAKE\EStor_Template.mmh.

Edit -the newly created file and modify the following macros:
- DEFAULT_FILE_BUF_SIZE This -macro sets the default file buffer size in bytes used in RFileBuf objects. -It must not be less than 1536 bytes.
- MAX_READ_AHEAD_VALUE This -macro sets the maximum RFileBuf 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 DEFAULT_FILE_BUF_SIZE
- FILE_BLOCK_SIZE This -macro sets the file-system block size for RFileBuf. 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 MAX_READ_AHEAD_VALUE. -It must also be a power of 2
Rebuild STORE then DBMS.

Domain Name -Daemon

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.

In the -file ...\os\networkingsrv\tcpiputils\dnd\inc\listener.h

const TUint KDndNumResolver = 31 ;

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

In the file

...\os\networkingsrv\tcpiputils\dnd\inc\llmnrresponder.h const TInt KLlmnrMaxEnabled = 15 ;

NOTE: You -must ensure that there is at least one resolver enabled for each LLMNR-enabled -network interface (NIF).

Heap Configuration

Minimum heap cell size

You can set the minimum heap cell -size used by the RHeap 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.

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.

Typical values to experiment -with are 0, 4, 8, 16, 32 and 64.

You set the value using a patchdata statement -in an OBY (or IBY) file.

-patchdata [ekern.exe|euser.dll] @ KHeapMinCellSize <NewValueForTheConstData> -

For example

-patchdata ekern.exe @ KHeapMinCellSize 32 - -patchdata euser.dll @ KHeapMinCellSize 32 -

Hysteresis window size

You can configure how the memory allocated -by the RHeap class is returned to the system.

The -heap grows in fixed size chunks. You can specify how quickly it shrinks (the -amount of hysteresis) by setting KHeapShrinkHysRatio.

The -value of KHeapShrinkHysRatio 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.

The default value of KHeapShrinkHysRatio 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.

You set the -value using a patchdata statement in an OBY (or IBY) file. -For example,

-patchdata ekern.exe @ KHeapShrinkHysRatio 1.5 - -patchdata euser.dll @ KHeapShrinkHysRatio 1.5 -

Recognizer -Loading

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

You -can enable or disable load-on-demand and specify the delay before unloading -using the patchdata statement in an OBY (or IBY) file.

patchdata apserv.dll @ KApaLoadDataRecognizersOnDemand <newvalue>

The -default newvalue is 0 which means that recognizers are loaded -at boot. A value of 1 specifies that recognizers will be loaded on demand.

patchdata apserv.dll @ KApaUnloadRecognizersTimeout <newvalue>

The -defaultnewvalue is 10000000 (10 seconds in milliseconds).

Secure Backup -Optimisation

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 sbeconfig.xml in -the private directory of the secure backup engine. The default size of the -chunk is 2MB.

-<?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> -

Server shutdown -behaviour

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.

You can configure the shutdown -behaviour of several key Symbian servers.

Message Server

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 ../generic/messaging/framework/server/group/messageserver.iby

For always-on include msgs.dll in -your ROM
For transitive behaviour -include msgs_autoshutdown.dll in your ROM

Contacts Server

The behaviour of the Contacts Server is determined -by a command line argument passed to cntsrv.exe.

The -default behaviour is transitive. For always-on behaviour you must start the -server use the -nontransient option in your system startup -file.

-START_PROCESS_INFO - { - path = "Z:\\sys\\bin\\cntsrv.exe"; - args = "-nontransient"; - ... - }

Agenda Server

The behaviour of the Agenda Server is determined -by a command line argument passed to agsvexe.exe.

The -default behaviour is transitive. For always-on behaviour you must start the -server use the -nontransient option in your system startup -file.

-START_PROCESS_INFO - { - path = "Z:\\sys\\bin\\agsvexe.exe"; - args = "-nontransient"; - ... - }

Window Server

Flicker Free Redraw and Transparency

You can configure the -drawing behaviour of the window server by enabling or disabling support forflicker -free redraw and transparency.

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).

An off-screen bitmap -to reduce redraw flicker. Drawing commands between BeginRedraw and EndRedraw commands -are committed to the off-screen bitmap. Only when EndRedraw is -called does the window server update the screen with the contents of the off-screen -bitmap.
A transparency bitmap -to support transparent windows.

The allocation of these bitmaps can be configured in Wsini.ini.

The presence of the -keyword FLICKERFREEREDRAW causes the off-screen bitmap to -be allocated.
The presence of the -keyword TRANSPARENCY causes both the off-screen and -transparency bitmaps to be allocated.
If neither keyword is -present no full-screen bitmaps are allocated.

In practice flicker free redraw makes a noticeable improvement -to most UIs. If a UI uses transparent windows both bitmaps must be enabled.

The default window server command buffer

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 (EClientBufferSize) -which is typically the minimum of 640 bytes. Applications can override the -default whenever they create an RWsSession.

The default -buffer size is defined in ...\os\graphics\windowing\windowserver\SERVER\w32cmd.h

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.

NOTE: Increasing -the buffer size to reduce flicker is less effective than using the FICKERFREEREDRAW feature -described above.

+ + + + + +Adjustable +Performance Configuration +

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.

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.

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.

Bitmaps
Central Repository
Comms Server
Database Management System (DBMS)
Domain Name Daemon
Heap Configuration
Recognizer Loading
Secure Backup
Server shutdown behaviour
Window Server

Bitmaps

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.

Bitmap compression ratio configuration

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.

A +bitmap stored in a compressed format has to be decompressed before it can +be displayed.

A compile-time macro, KCompressionThreshold, +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.

Location: ...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP
Source: /* +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 +

You must recompile FBServ for this change to take effect.

Bitmap storage location

Bitmaps are stored in different memory +locations according to their size.

Small bitmaps are stored +in a normal heap called a shared chunk.
Large bitmaps are stored +in special area of memory, called the large chunk or pile, that is managed +by the font and bitmap server.

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.

A compile-time macro, KMaxLargeBitmapAlloc, +specifies the cut-off point (in kB) at which a bitmap is considered large +and, therefore, stored in the large chunk.

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.

Location: ...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP
Source: /* +configurable value to control bitmap heap defragmentation by setting large bitmap threshold +*/ +MACRO KMaxLargeBitmapAlloc=0x4000 + +

You must recompile FBServ for this change to take effect.

Large chunk defragmentation

Deleting large bitmaps results +in fragmentation of the large chunk (see above).

A compile-time +macro, KFreeCellCountLimit, specifies the number of free +cells that must exist in the large chunk before it gets defragmented.

Location: ...\os\graphics\fbs\fontandbitmapserver\group\FBSCLI.MMP
Source: /* +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 +

A smaller value will result in less wasted RAM but poorer performance +as the defragmentation process will run more often.

NOTE: 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 +(KMaxLargeBitmapAlloc x KFreeCellCountLimit). +For the default values this is 160kB.

You must recompile FBServ for +this change to take effect.

Using bitmap fonts

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.

The performance +trade off is dependant on the font rasteriser though once a font has been +rasterised it can be cached in bitmap form.

NOTE: You can be pre-rasterise +FreeType fonts into bitmap fonts for inclusion in ROMs using the ttf2bdf tool. +Though the tool is supplied with the Symbian platform (as part of the graphics_font CBR +component) it is not supported. There may also be legal and licencing issues +to consider when pre-rasterising ronts in this way.

Central Repository

The +Central Repository caches individual repositories in RAM after clients have +closed their sessions. You can configure the sizeof the cache and the length +of time that entries persist by editing the central repository INI file \private\10202be9\centrep.ini

[CoarseGrainedCache] +size= <size in bytes> +timeout= <timeout in microseconds>

Increasing the size +of the cache and the timeout improve performance at the cost of increased +RAM use.

NOTE: If the cache fills up the oldest entries are +pushed out before they timeout.

Comms Server

You +can adjust the size of the MBuf pool. The MBuf pool +is used for creating buffers for communication data.

The value is +set in ...\os\commsfw\commsprocess\commsrootserverconfig\etc\c32start.ini.

+[Global] +MBufPoolSize=<initial size in bytes>,<max size in bytes> //The default is MBufPoolSize=262144,262144.

NOTE: 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.

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.

Database Management +System (DBMS)

The size of the cache used by DBMS and the +size of the buffer 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.

Adjust the sizes of the cache and buffer +as follows:

Define the constants SYMBIAN_CUSTOM_DBMS_CACHE_SIZES and SYMBIAN_CUSTOM_STORE_BUFFER_SIZES in the appropriate HRH file in \epoc32\include\variant.
Create ...\os\persistentdata\persistentstorage\dbms\bmake\EDbms.mmh by +copying ...\os\persistentdata\persistentstorage\dbms\bmake\EDbms_Template.mmh.

Edit +the newly created file and modify the following macros:
- PAGE_CACHE_SIZE - +the size of the page cache used to cache index information in a database. +It must not be less than 8 pages.
- MAX_CLUSTER_CACHE_SIZE - +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.
Create ...\os\persistentdata\persistentstorage\store\BMAKEEStor.mmh by +copying ...\os\persistentdata\persistentstorage\store\BMAKE\EStor_Template.mmh.

Edit +the newly created file and modify the following macros:
- DEFAULT_FILE_BUF_SIZE This +macro sets the default file buffer size in bytes used in RFileBuf objects. +It must not be less than 1536 bytes.
- MAX_READ_AHEAD_VALUE This +macro sets the maximum RFileBuf 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 DEFAULT_FILE_BUF_SIZE
- FILE_BLOCK_SIZE This +macro sets the file-system block size for RFileBuf. 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 MAX_READ_AHEAD_VALUE. +It must also be a power of 2
Rebuild STORE then DBMS.

Domain Name +Daemon

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.

In the +file ...\os\networkingsrv\tcpiputils\dnd\inc\listener.h

const TUint KDndNumResolver = 31 ;

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

In the file

...\os\networkingsrv\tcpiputils\dnd\inc\llmnrresponder.h const TInt KLlmnrMaxEnabled = 15 ;

NOTE: You +must ensure that there is at least one resolver enabled for each LLMNR-enabled +network interface (NIF).

Heap Configuration

Minimum heap cell size

You can set the minimum heap cell +size used by the RHeap 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.

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.

Typical values to experiment +with are 0, 4, 8, 16, 32 and 64.

You set the value using a patchdata statement +in an OBY (or IBY) file.

+patchdata [ekern.exe|euser.dll] @ KHeapMinCellSize <NewValueForTheConstData> +

For example

+patchdata ekern.exe @ KHeapMinCellSize 32 + +patchdata euser.dll @ KHeapMinCellSize 32 +

Hysteresis window size

You can configure how the memory allocated +by the RHeap class is returned to the system.

The +heap grows in fixed size chunks. You can specify how quickly it shrinks (the +amount of hysteresis) by setting KHeapShrinkHysRatio.

The +value of KHeapShrinkHysRatio 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.

The default value of KHeapShrinkHysRatio 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.

You set the +value using a patchdata statement in an OBY (or IBY) file. +For example,

+patchdata ekern.exe @ KHeapShrinkHysRatio 1.5 + +patchdata euser.dll @ KHeapShrinkHysRatio 1.5 +

Recognizer +Loading

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

You +can enable or disable load-on-demand and specify the delay before unloading +using the patchdata statement in an OBY (or IBY) file.

patchdata apserv.dll @ KApaLoadDataRecognizersOnDemand <newvalue>

The +default newvalue is 0 which means that recognizers are loaded +at boot. A value of 1 specifies that recognizers will be loaded on demand.

patchdata apserv.dll @ KApaUnloadRecognizersTimeout <newvalue>

The +defaultnewvalue is 10000000 (10 seconds in milliseconds).

Secure Backup +Optimisation

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 sbeconfig.xml in +the private directory of the secure backup engine. The default size of the +chunk is 2MB.

+<?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> +

Server shutdown +behaviour

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.

You can configure the shutdown +behaviour of several key Symbian servers.

Message Server

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 ../generic/messaging/framework/server/group/messageserver.iby

For always-on include msgs.dll in +your ROM
For transitive behaviour +include msgs_autoshutdown.dll in your ROM

Contacts Server

The behaviour of the Contacts Server is determined +by a command line argument passed to cntsrv.exe.

The +default behaviour is transitive. For always-on behaviour you must start the +server use the -nontransient option in your system startup +file.

+START_PROCESS_INFO + { + path = "Z:\\sys\\bin\\cntsrv.exe"; + args = "-nontransient"; + ... + }

Agenda Server

The behaviour of the Agenda Server is determined +by a command line argument passed to agsvexe.exe.

The +default behaviour is transitive. For always-on behaviour you must start the +server use the -nontransient option in your system startup +file.

+START_PROCESS_INFO + { + path = "Z:\\sys\\bin\\agsvexe.exe"; + args = "-nontransient"; + ... + }

Window Server

Flicker Free Redraw and Transparency

You can configure the +drawing behaviour of the window server by enabling or disabling support forflicker +free redraw and transparency.

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).

An off-screen bitmap +to reduce redraw flicker. Drawing commands between BeginRedraw and EndRedraw commands +are committed to the off-screen bitmap. Only when EndRedraw is +called does the window server update the screen with the contents of the off-screen +bitmap.
A transparency bitmap +to support transparent windows.

The allocation of these bitmaps can be configured in Wsini.ini.

The presence of the +keyword FLICKERFREEREDRAW causes the off-screen bitmap to +be allocated.
The presence of the +keyword TRANSPARENCY causes both the off-screen and +transparency bitmaps to be allocated.
If neither keyword is +present no full-screen bitmaps are allocated.

In practice flicker free redraw makes a noticeable improvement +to most UIs. If a UI uses transparent windows both bitmaps must be enabled.

The default window server command buffer

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 (EClientBufferSize) +which is typically the minimum of 640 bytes. Applications can override the +default whenever they create an RWsSession.

The default +buffer size is defined in ...\os\graphics\windowing\windowserver\SERVER\w32cmd.h

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.

NOTE: Increasing +the buffer size to reduce flicker is less effective than using the FICKERFREEREDRAW feature +described above.

\ No newline at end of file