diff -r 43e37759235e -r 51a74ef9ed63 Symbian3/SDK/Source/GUID-2FAB8281-569A-52BE-8BC8-A2D378068706.dita
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-2FAB8281-569A-52BE-8BC8-A2D378068706.dita	Wed Mar 31 11:11:55 2010 +0100
@@ -0,0 +1,45 @@
+<?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-2FAB8281-569A-52BE-8BC8-A2D378068706" xml:lang="en"><title>Caching</title><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>In Symbian OS v9.3 and earlier, index entries were stored in a single index
+file in a permanent file store and the entire file was loaded into RAM on
+start up. In Symbian^3 index entries are stored in an SQL database and only
+the most recently used index entries are cached in RAM. </p>
+<p>The following figure shows how a client request is completed using the
+cache functionality in the Message Server. </p>
+<fig id="GUID-43D2AE30-9221-500A-B934-5D3636168273">
+<title>           Caching architecture          </title>
+<image href="GUID-53A2CA11-2ABF-5ED7-A26C-7BE9FD9A1D22_d0e284883_href.png" placement="inline"/>
+</fig>
+<section id="GUID-D3F3D019-736E-4527-8099-9BE8883CF37C"><title>Creating and
+maintaining free space in memory</title> <p>Memory allocation to the cache
+is done incrementally, to reduce the Message Server start up time. When the
+Message Server starts, only a percentage of the maximum cache size (<codeph>MsvMaximumCacheSize</codeph>)
+is allocated to cache. The percentage is specified by the <codeph>MsvInitialCacheCreation</codeph> parameter.
+The next iteration of memory allocation is not initiated until the memory
+threshold (set using the <codeph>MsvCacheThreshold</codeph> parameter) is
+reached. The subsequent memory allocation is always done by a low priority
+active object. </p> <p><b>Example</b> </p> <p>The memory allocation strategy
+is illustrated in the following figures, based on the default values (shown
+in the preceding table). </p> <p>When Message Server starts, the cache is
+created with an initial size of 410KB (40 percent of 1024KB). If 70 percent
+of the free space in the cache gets used the server allocates an additional
+205KB (20 percent of 1024). </p> <fig id="GUID-CA4A08C8-C4E8-575F-8F03-F3D1F6579E5F">
+<image href="GUID-B459E37A-BECE-5087-9827-C93310890674_d0e284915_href.png" placement="inline"/>
+</fig> <p>Message Server can make two further 205KB allocations which it does
+as use reaches 70 percent of the memory already allocated. </p> <fig id="GUID-21A40614-046B-56DD-9DDD-34B2F9681B5C">
+<image href="GUID-107F7BC4-F776-512D-AD6F-1674B7ED19B5_d0e284923_href.png" placement="inline"/>
+</fig> <p>If more than 70 percent of the first two allocated memory chunks
+is used, an additional 20 percent of memory is added to the free space. </p> <fig id="GUID-EBF4FF85-D6D6-518C-9391-C3AFF8821F83">
+<image href="GUID-5E380880-9DBB-51D7-8942-829C6FD788C2_d0e284931_href.png" placement="inline"/>
+</fig> </section>
+</conbody></concept>
\ No newline at end of file