Google, July 2011
In order to test LevelDB's performance, we benchmark it against other well-established database implementations. We compare LevelDB (revision 39) against SQLite3 (version 3.7.6.3) and Kyoto Cabinet's (version 1.2.67) TreeDB (a B+Tree based key-value store). We would like to acknowledge Scott Hess and Mikio Hirabayashi for their suggestions and contributions to the SQLite3 and Kyoto Cabinet benchmarks, respectively.
+In order to test LevelDB's performance, we benchmark it against other well-established database implementations. We compare LevelDB (revision 39) against SQLite3 (version 3.7.6.3) and Kyoto Cabinet's (version 1.2.67) TreeDB (a B+Tree based key-value store). We would like to acknowledge Scott Hess and Mikio Hirabayashi for their suggestions and contributions to the SQLite3 and Kyoto Cabinet benchmarks, respectively.
Benchmarks were all performed on a six-core Intel(R) Xeon(R) CPU X5650 @ 2.67GHz, with 12288 KB of total L3 cache and 12 GB of DDR3 RAM at 1333 MHz. (Note that LevelDB uses at most two CPUs since the benchmarks are single threaded: one to run the benchmark, and one for background compactions.) We ran the benchmarks on two machines (with identical processors), one with an Ext3 file system and one with an Ext4 file system. The machine with the Ext3 file system has a SATA Hitachi HDS721050CLA362 hard drive. The machine with the Ext4 file system has a SATA Samsung HD502HJ hard drive. Both hard drives spin at 7200 RPM and have hard drive write-caching enabled (using `hdparm -W 1 [device]`). The numbers reported below are the median of three measurements.
diff --git a/doc/index.md b/doc/index.md index 3d9a25805b..e728178a81 100644 --- a/doc/index.md +++ b/doc/index.md @@ -325,7 +325,7 @@ sizes. Each block is individually compressed before being written to persistent storage. Compression is on by default since the default compression method is -very fast, and is automatically disabled for uncompressible data. In rare cases, +very fast, and is automatically disabled for incompressible data. In rare cases, applications may want to disable compression entirely, but should only do so if benchmarks show a performance improvement: diff --git a/util/env_posix.cc b/util/env_posix.cc index 86571059ba..8a33534ed5 100644 --- a/util/env_posix.cc +++ b/util/env_posix.cc @@ -218,7 +218,7 @@ class PosixMmapReadableFile final : public RandomAccessFile { // over the ownership of the region. // // |mmap_limiter| must outlive this instance. The caller must have already - // aquired the right to use one mmap region, which will be released when this + // acquired the right to use one mmap region, which will be released when this // instance is destroyed. PosixMmapReadableFile(std::string filename, char* mmap_base, size_t length, Limiter* mmap_limiter) @@ -741,7 +741,7 @@ class PosixEnv : public Env { // Instances are constructed on the thread calling Schedule() and used on the // background thread. // - // This structure is thread-safe beacuse it is immutable. + // This structure is thread-safe because it is immutable. struct BackgroundWorkItem { explicit BackgroundWorkItem(void (*function)(void* arg), void* arg) : function(function), arg(arg) {} diff --git a/util/env_windows.cc b/util/env_windows.cc index 0a48c3fb52..8897e2aa26 100644 --- a/util/env_windows.cc +++ b/util/env_windows.cc @@ -689,7 +689,7 @@ class WindowsEnv : public Env { // Instances are constructed on the thread calling Schedule() and used on the // background thread. // - // This structure is thread-safe beacuse it is immutable. + // This structure is thread-safe because it is immutable. struct BackgroundWorkItem { explicit BackgroundWorkItem(void (*function)(void* arg), void* arg) : function(function), arg(arg) {}