mirror of
https://github.com/bitcoin/bitcoin.git
synced 2026-01-19 23:03:45 +01:00
Merge bitcoin/bitcoin#33641: Update leveldb subtree to latest master
f21162d819Squashed 'src/leveldb/' changes from aba469ad6a..cad64b151d (fanquake) Pull request description: Rather than continue to close PRs/"Send these upstream" i.e: #33638, #33148, #22664, #13781; just fix the typos. Includes https://github.com/bitcoin-core/leveldb-subtree/pull/57. ACKs for top commit: l0rinc: ACK54ffe3de5bcedwies: ACK54ffe3dstickies-v: ACK54ffe3de5bTree-SHA512: cc4d758ee95a1943f14e800472dfef24d5598a1dfafede32300821bc27e02a80ae97ea12ee87643b395b204262c7bc28e64d421a3d375d46bef7782381fd4362
This commit is contained in:
@@ -49,7 +49,7 @@ mkdir build
|
||||
cd build
|
||||
cmake -G "Visual Studio 15" ..
|
||||
```
|
||||
The default default will build for x86. For 64-bit run:
|
||||
The default will build for x86. For 64-bit run:
|
||||
|
||||
```cmd
|
||||
cmake -G "Visual Studio 15 Win64" ..
|
||||
|
||||
@@ -2194,7 +2194,7 @@ TEST(DBTest, Randomized) {
|
||||
if (i == 0 || !rnd.OneIn(10)) {
|
||||
k = RandomKey(&rnd);
|
||||
} else {
|
||||
// Periodically re-use the same key from the previous iter, so
|
||||
// Periodically reuse the same key from the previous iter, so
|
||||
// we have multiple entries in the write batch for the same key
|
||||
}
|
||||
if (rnd.OneIn(2)) {
|
||||
|
||||
@@ -25,7 +25,7 @@ class SnapshotImpl : public Snapshot {
|
||||
friend class SnapshotList;
|
||||
|
||||
// SnapshotImpl is kept in a doubly-linked circular list. The SnapshotList
|
||||
// implementation operates on the next/previous fields direcly.
|
||||
// implementation operates on the next/previous fields directly.
|
||||
SnapshotImpl* prev_;
|
||||
SnapshotImpl* next_;
|
||||
|
||||
|
||||
@@ -83,7 +83,7 @@ div.bsql {
|
||||
<p>Google, July 2011</p>
|
||||
<hr>
|
||||
|
||||
<p>In order to test LevelDB's performance, we benchmark it against other well-established database implementations. We compare LevelDB (revision 39) against <a href="http://www.sqlite.org/">SQLite3</a> (version 3.7.6.3) and <a href="http://fallabs.com/kyotocabinet/spex.html">Kyoto Cabinet's</a> (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.</p>
|
||||
<p>In order to test LevelDB's performance, we benchmark it against other well-established database implementations. We compare LevelDB (revision 39) against <a href="http://www.sqlite.org/">SQLite3</a> (version 3.7.6.3) and <a href="https://dbmx.net/kyotocabinet/spex.html">Kyoto Cabinet's</a> (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.</p>
|
||||
|
||||
<p>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.</p>
|
||||
|
||||
|
||||
@@ -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:
|
||||
|
||||
|
||||
@@ -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) {}
|
||||
|
||||
@@ -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) {}
|
||||
|
||||
Reference in New Issue
Block a user