Symbian3/SDK/Source/GUID-2FAB8281-569A-52BE-8BC8-A2D378068706.dita
author Dominic Pinkman <dominic.pinkman@nokia.com>
Fri, 11 Jun 2010 12:39:03 +0100
changeset 8 ae94777fff8f
parent 7 51a74ef9ed63
child 13 48780e181b38
permissions -rw-r--r--
Week 23 contribution of SDK documentation content. See release notes for details. Fixes bugs Bug 2714, Bug 462.

<?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_d0e281197_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_d0e281229_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_d0e281237_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_d0e281245_href.png" placement="inline"/>
</fig> </section>
</conbody></concept>