1 Introduction
1.1 Purpose and Scope
This document gives some tips on how to write applications that do not unnecessarily use up memory. Some of the recommendations are based upon common sense, others may look quite unexpected as due to the way some system servers work a software engineer may not realise that certain operations are using up memory in system servers.
2 General
2.1 TBuf variables
As TBufvariables take up a fixed amount of space (on the heap in case of a C class member variable or on the stack if being a local variable) be very careful when to use these. Also several built-in Symbian type definitions (e.g. TFileName) are a TBuf. Quite often it is much more efficient to use an HBufC(pointer) variable, which only needs to allocate exactly the amount of memory needed, and must always be created on the stack. In general this can be done quite easily if the (maximum) length of the string is known in advance (e.g. it can be calculated as it is depends on some other string length). In other cases even a TPtr variable can be used, e.g. when there is no need for string manipulation but a string may take up different values according to some criteria (like 'Yes' or 'No' depending on a boolean variable).
2.2 Fixed size arrays
Only use fixed size arrays if in all (or most) cases the entire array will be used. In other cases use one of the Symbian variable length array types.
2.3 Do not use recursive functions
Try to avoid using recursive functions (especially if a good non-recursive algorithm is available) as the stack size is very limited. If these are still needed limit the amount of stack used per recursion level by allocating local variables on the heap. In that case do use the Cleanup Stack to ensure releasing the memory in case of leaves.
3 Bitmaps
3.1 Icon cache
The icon cache will cache bitmaps, even if these are never used again. Rotated bitmaps will not be cached.
4 File Server
4.1 File Server sessions
Creating a file server sessions is both inefficient in terms of CPU time and memory. Within one application the most efficient way is to only open one session to the file server (e.g. at application startup) and use this everywhere, only closing the session when exiting the application.
4.2 Transferring file handles between clients and server
When transferring file handles take care that handles are always adopted, even in error scenarios. This is in particular essential when file handles are transferred from a server to a client. If a file handle is not adopted by a client that means that the new File Server sub-session created in order to transfer the handle is left open and will only be closed if the File Server session in which it is contained closes. This may never happen in case of a permanent server.
4.3 Closing File Server sub-sessions
Many operations create a File Server sub-session. Probably the most commonly used is opening a file via the RFile class. Each sub-session allocates memory on the File Server heap. If File Server sub-sessions are left open they will eventually be closed when their File Server session closes. However in case of servers it is very likely that the enclosing File Server session is never closed. Therefore it is essential to take care that these sub-session are closed, especially in case of error scenarios. The Cleanup Stack can often be used for this means.
