From b9ef9141ba31410fbe21c2c2eb0b8fefaec95be7 Mon Sep 17 00:00:00 2001
From: "gabor@google.com"
 <gabor@google.com@62dab493-f737-651d-591e-8d6aee1b9529>
Date: Wed, 27 Jul 2011 14:29:59 +0000
Subject: [PATCH] Minor typos in benchmark page.

git-svn-id: https://leveldb.googlecode.com/svn/trunk@44 62dab493-f737-651d-591e-8d6aee1b9529
---
 doc/benchmark.html | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/doc/benchmark.html b/doc/benchmark.html
index 6a79bc703..f8421187c 100644
--- a/doc/benchmark.html
+++ b/doc/benchmark.html
@@ -103,7 +103,7 @@ div.bsql {
 </ul>
 
 <h2>1. Baseline Performance</h2>
-<p>This section gives the baseline performance of a all of the
+<p>This section gives the baseline performance of all the
 databases.  Following sections show how performance changes as various
 parameters are varied.  For the baseline:</p>
 <ul>
@@ -234,7 +234,7 @@ of sequential writes.  However SQLite3 sees a significant slowdown
 writes.  This is because each random batch write in SQLite3 has to
 update approximately as many pages as there are keys in the batch.</p>
 
-<h3>C. Synchronous writes</h3>
+<h3>C. Synchronous Writes</h3>
 <p>In the following benchmark, we enable the synchronous writing modes
 of all of the databases.  Since this change significantly slows down the
 benchmark, we stop after 10,000 writes.</p>
@@ -329,7 +329,7 @@ better without compression than with compression.  Presumably this is
 because TreeDB's compression library (LZO) is more expensive than
 LevelDB's compression library (Snappy).<p>
 
-<h3>E. Using more memory</h3>
+<h3>E. Using More Memory</h3>
 <p>We increased the overall cache size for each database to 128 MB. For LevelDB, we partitioned 128 MB into a 120 MB write buffer and 8 MB of cache (up from 2 MB of write buffer and 2 MB of cache). For SQLite3, we kept the page size at 1024 bytes, but increased the number of pages to 131,072 (up from 4096). For TreeDB, we also kept the page size at 1024 bytes, but increased the cache size to 128 MB (up from 4 MB).</p>
 <h4>Sequential Writes</h4>
 <table class="bn">
@@ -370,8 +370,8 @@ because a larger write buffer reduces the need to merge sorted files
 performance goes up because the entire database is available in memory
 for fast in-place updates.</p>
 
-  <h2>2. Read Performance under Different Configurations</h2>
-<h3>A. Larger caches</h3>
+  <h2>3. Read Performance under Different Configurations</h2>
+<h3>A. Larger Caches</h3>
 <p>We increased the overall memory usage to 128 MB for each database.
 For LevelDB, we allocated 8 MB to LevelDB's write buffer and 120 MB
 to LevelDB's cache. The other databases don't differentiate between a
@@ -414,7 +414,7 @@ when the caches are enlarged.  In particular, TreeDB seems to make
 very effective use of a cache that is large enough to hold the entire
 database.</p>
 
-<h3>B. No compression reads </h3>
+<h3>B. No Compression Reads </h3>
 <p>For this benchmark, we populated a database with 1 million entries consisting of 16 byte keys and 100 byte values. We compiled LevelDB and Kyoto Cabinet without compression support, so results that are read out from the database are already uncompressed. We've listed the SQLite3 baseline read performance as a point of comparison.</p>
 <h4>Sequential Reads</h4>
 <table class="bn">