Compare Revisions

Performance

Change Revisions

Revision 60949:

Revision 60949 by another_sam on

Revision 60950:

Revision 60950 by peter.kehl on

Title:
Performance
Performance
Slug:
Storage/Performance
Storage/Performance
Tags:
Storage, "Toolkit API"
Storage, "Toolkit API"
Content:

Revision 60949
Revision 60950
n13    <h3 name="Transactions">n13    <h3 id="Transactions" name="Transactions">
n20      If you are not using the advanced caching discussed below, n
>the database cache in memory is cleared at the end of each transa 
>ction. This is another reason to use transactions, even if you ar 
>e only executing read operations. 
21    </p>
22    <p>
n25    <h3 name="Queries">n22    <h3 id="Queries" name="Queries">
n55    <h3 name="Caching">n52    <h3 id="Caching" name="Caching">
n62      By default, it only keeps the pages in memory during a trann59      In the past, it flushed the cache at the end of a transacti
>saction (if you don't explicitly open a transaction, one will be >on (by default). In order to keep the cache active between transa
>opened for you enclosing each individual statement). At the end o>ctions, you needed to have a second connection with a 'dummy' (an
>f a transaction, the cache is flushed. If you subsequently begin >d schema changing) transaction. That is not needed now.
>a new transaction, the pages you need will be re-read from disk ( 
>or hopefully the OS cache). This makes even simple operations blo 
>ck on OS file reads, which can be prohibitive on some systems wit 
>h bad disk caches or networked drives. 
n67    <h4 name="Keeping_the_cache_between_transactions">n64    <h4 id="Sharing_the_cache_between_connections" name="Sharing_
 >the_cache_between_connections">
68      Keeping the cache between transactions65      Sharding the cache between connections
n71      Storage enables the <a class="external" href="http://www.sqn68      By default, Storage enables the <a class="external" href="h
>lite.org/sharedcache.html">sqlite shared-cache mode</a>) which ma>ttp://www.sqlite.org/sharedcache.html">sqlite shared-cache mode</
>kes multiple connections to the same database share the same cach>a> which makes multiple connections to the same database share th
>e. Because the cache is not threadsafe, this unfortunately means >e same cache. The cache is threadsafe. All you need to do is use 
>that you can not have different connections from different thread>Services.storage.openDatabase(file). Some features (virtual table
>s accessing the same database. However, the shared cache allows u>s, full text indexes) are not compatible with shared cache - then
>s to keep it live between transactions, instead of clearing it af> you need to use Services.storage.openUnsharedDatabase(file), whi
>ter each transaction as sqlite does by default.>ch doesn't share the cache. See <a href="/en/XPCOM_Interface_Refe
 >rence/mozIStorageService#openDatabase()">mozIStorageService#openD
 >atabase()</a>.
n73    <p>n70    <h3 id="Disk_writes">
74      If your application uses many small transactons, you can ge
>t a significant performance improvement by keeping the cache live 
> between transactions. This is done by using an extra "dummy" con 
>nection to the same database (it is important that you use exactl 
>y the same filename when opening these connections as determined  
>by <code>strcmp</code>). The dummy connection keeps a perpetually 
> open transaction which locks the cache in memory. Since the cach 
>e is shared with the main connection, the cache never expires. 
75    </p>
76    <p>
77      The dummy transaction must be one that locks a page in memo
>ry. A simple <code>BEGIN TRANSACTION</code> statement doesn't do  
>this because sqlite does the locking lazily. Therefore, you must  
>have a statement that modifies data. It might be tempting to run  
>a statement on the <code>sqlite_master</code> which contains the  
>information on the tables and indices in the database. However, i 
>f your application is initializing the database for the first tim 
>e, this table will be empty and the cache won't be locked. nsNavH 
>istory::StartDummyStatement creates a dummy table with a single e 
>lement in it for this purpose. 
78    </p>
79    <p>
80      It is important to note that when a statement is open, the 
>database schema cannot be modified. This means that when the dumm 
>y transaction is running, you cannot create or modify any tables  
>or indices, or vacuum the database. You will have to stop the dum 
>my transaction, do the schema-modifying operation, and restart it 
>. 
81    </p>
82    <h3>
t101    <h3>t89    <h3 id="Vacuuming_and_zero-fill">

Back to History