Adjustable Performance Configuration

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:

1. Define the constants SYMBIAN_CUSTOM_DBMS_CACHE_SIZES and SYMBIAN_CUSTOM_STORE_BUFFER_SIZES in the appropriate HRH file in \epoc32\include\variant.

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

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

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