Symbian3/SDK/Source/GUID-2FAB8281-569A-52BE-8BC8-A2D378068706.dita
changeset 0 89d6a7a84779
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-2FAB8281-569A-52BE-8BC8-A2D378068706.dita	Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,46 @@
+<?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 versions earlier than 9.4, 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 OS version 9.5 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_d0e256631_href.png" placement="inline"/>
+</fig>
+<section><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_d0e256663_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_d0e256671_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_d0e256679_href.png" placement="inline"/>
+</fig> </section>
+</conbody></concept>
\ No newline at end of file