Inside Bitcoin
Opening the selected file…
Inside Bitcoin
Opening the selected file…
The code behind the network, with room to understand it.
Release published 2026-10-28 · Snapshot fetched 2026-11-01. Latest stable release at fetch time; development branches and Git history are excluded. Only the selected code window and visible folders load here.
251<td class="c2">7 ops/sec</td>252<td class="c3"><div class="bkct" style="width:27px"> </div></td>253<td class="c4">(0.0004x baseline)</td></tr>254<tr><td class="c1">SQLite3</td>255<td class="c2">88 ops/sec</td>256<td class="c3"><div class="bsql" style="width:315px"> </div></td>257<td class="c4">(0.002x baseline)</td></tr>258</table>259<h4>Random Writes</h4>260<table class="bn">261<tr><td class="c1">LevelDB</td>262<td class="c2">100 ops/sec</td>263<td class="c3"><div class="bldb" style="width:350px"> </div></td>264<td class="c4">(0.015x baseline)</td></tr>265<tr><td class="c1">Kyoto TreeDB</td>266<td class="c2">8 ops/sec</td>267<td class="c3"><div class="bkct" style="width:29px"> </div></td>268<td class="c4">(0.001x baseline)</td></tr>269<tr><td class="c1">SQLite3</td>270<td class="c2">88 ops/sec</td>271<td class="c3"><div class="bsql" style="width:314px"> </div></td>272<td class="c4">(0.009x baseline)</td></tr>273</table>275<p>Also see the <code>ext4</code> performance numbers below276since synchronous writes behave significantly differently277on <code>ext3</code> and <code>ext4</code>.</p>279<h3>D. Turning Compression Off</h3>281<p>In the baseline measurements, LevelDB and TreeDB were using282light-weight compression283(<a href="http://code.google.com/p/snappy/">Snappy</a> for LevelDB,284and <a href="http://www.oberhumer.com/opensource/lzo/">LZO</a> for285TreeDB). SQLite3, by default does not use compression. The286experiments below show what happens when compression is disabled in287all of the databases (the SQLite3 numbers are just a copy of288its baseline measurements):</p>290<h4>Sequential Writes</h4>291<table class="bn">292<tr><td class="c1">LevelDB</td>293<td class="c2">594,000 ops/sec</td>294<td class="c3"><div class="bldb" style="width:350px"> </div></td>295<td class="c4">(0.76x baseline)</td></tr>296<tr><td class="c1">Kyoto TreeDB</td>297<td class="c2">485,000 ops/sec</td>298<td class="c3"><div class="bkct" style="width:239px"> </div></td>299<td class="c4">(1.42x baseline)</td></tr>300<tr><td class="c1">SQLite3</td>301<td class="c2">48,600 ops/sec</td>302<td class="c3"><div class="bsql" style="width:29px"> </div></td>303<td class="c4">(1.00x baseline)</td></tr>304</table>305<h4>Random Writes</h4>306<table class="bn">307<tr><td class="c1">LevelDB</td>308<td class="c2">135,000 ops/sec</td>309<td class="c3"><div class="bldb" style="width:296px"> </div></td>310<td class="c4">(0.82x baseline)</td></tr>311<tr><td class="c1">Kyoto TreeDB</td>312<td class="c2">159,000 ops/sec</td>313<td class="c3"><div class="bkct" style="width:350px"> </div></td>314<td class="c4">(1.80x baseline)</td></tr>315<tr><td class="c1">SQLite3</td>316<td class="c2">9,860 ops/sec</td>317<td class="c3"><div class="bsql" style="width:22px"> </div></td>318<td class="c4">(1.00x baseline)</td></tr>319</table>321<p>LevelDB's write performance is better with compression than without322since compression decreases the amount of data that has to be written323to disk. Therefore LevelDB users can leave compression enabled in324most scenarios without having worry about a tradeoff between space325usage and performance. TreeDB's performance on the other hand is326better without compression than with compression. Presumably this is327because TreeDB's compression library (LZO) is more expensive than328LevelDB's compression library (Snappy).<p>330<h3>E. Using More Memory</h3>331<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>332<h4>Sequential Writes</h4>333<table class="bn">334<tr><td class="c1">LevelDB</td>335<td class="c2">812,000 ops/sec</td>336<td class="c3"><div class="bldb" style="width:350px"> </div></td>337<td class="c4">(1.04x baseline)</td></tr>338<tr><td class="c1">Kyoto TreeDB</td>339<td class="c2">321,000 ops/sec</td>340<td class="c3"><div class="bkct" style="width:138px"> </div></td>341<td class="c4">(0.94x baseline)</td></tr>342<tr><td class="c1">SQLite3</td>343<td class="c2">48,500 ops/sec</td>344<td class="c3"><div class="bsql" style="width:21px"> </div></td>345<td class="c4">(1.00x baseline)</td></tr>346</table>347<h4>Random Writes</h4>348<table class="bn">349<tr><td class="c1">LevelDB</td>350<td class="c2">355,000 ops/sec</td>351<td class="c3"><div class="bldb" style="width:350px"> </div></td>352<td class="c4">(2.16x baseline)</td></tr>353<tr><td class="c1">Kyoto TreeDB</td>354<td class="c2">284,000 ops/sec</td>355<td class="c3"><div class="bkct" style="width:280px"> </div></td>356<td class="c4">(3.21x baseline)</td></tr>357<tr><td class="c1">SQLite3</td>358<td class="c2">9,670 ops/sec</td>359<td class="c3"><div class="bsql" style="width:10px"> </div></td>360<td class="c4">(0.98x baseline)</td></tr>361</table>363<p>SQLite's performance does not change substantially when compared to364the baseline, but the random write performance for both LevelDB and365TreeDB increases significantly. LevelDB's performance improves366because a larger write buffer reduces the need to merge sorted files367(since it creates a smaller number of larger sorted files). TreeDB's368performance goes up because the entire database is available in memory369for fast in-place updates.</p>371<h2>3. Read Performance under Different Configurations</h2>372<h3>A. Larger Caches</h3>373<p>We increased the overall memory usage to 128 MB for each database.374For LevelDB, we allocated 8 MB to LevelDB's write buffer and 120 MB375to LevelDB's cache. The other databases don't differentiate between a376write buffer and a cache, so we simply set their cache size to 128377MB.</p>378<h4>Sequential Reads</h4>379<table class="bn">380<tr><td class="c1">LevelDB</td>381<td class="c2">5,210,000 ops/sec</td>382<td class="c3"><div class="bldb" style="width:350px"> </div></td>383<td class="c4">(1.29x baseline)</td></tr>384<tr><td class="c1">Kyoto TreeDB</td>385<td class="c2">1,070,000 ops/sec</td>386<td class="c3"><div class="bkct" style="width:72px"> </div></td>387<td class="c4">(1.06x baseline)</td></tr>388<tr><td class="c1">SQLite3</td>389<td class="c2">609,000 ops/sec</td>390<td class="c3"><div class="bsql" style="width:41px"> </div></td>391<td class="c4">(1.59x baseline)</td></tr>392</table>394<h4>Random Reads</h4>395<table class="bn">396<tr><td class="c1">LevelDB</td>397<td class="c2">190,000 ops/sec</td>398<td class="c3"><div class="bldb" style="width:144px"> </div></td>399<td class="c4">(1.47x baseline)</td></tr>400<tr><td class="c1">Kyoto TreeDB</td>401<td class="c2">463,000 ops/sec</td>402<td class="c3"><div class="bkct" style="width:350px"> </div></td>403<td class="c4">(3.07x baseline)</td></tr>404<tr><td class="c1">SQLite3</td>405<td class="c2">186,000 ops/sec</td>406<td class="c3"><div class="bsql" style="width:141px"> </div></td>407<td class="c4">(1.39x baseline)</td></tr>408</table>410<p>As expected, the read performance of all of the databases increases411when the caches are enlarged. In particular, TreeDB seems to make412very effective use of a cache that is large enough to hold the entire413database.</p>415<h3>B. No Compression Reads </h3>416<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>417<h4>Sequential Reads</h4>418<table class="bn">419<tr><td class="c1">LevelDB</td>420<td class="c2">4,880,000 ops/sec</td>421<td class="c3"><div class="bldb" style="width:350px"> </div></td>422<td class="c4">(1.21x baseline)</td></tr>423<tr><td class="c1">Kyoto TreeDB</td>424<td class="c2">1,230,000 ops/sec</td>425<td class="c3"><div class="bkct" style="width:88px"> </div></td>426<td class="c4">(3.60x baseline)</td></tr>427<tr><td class="c1">SQLite3</td>428<td class="c2">383,000 ops/sec</td>429<td class="c3"><div class="bsql" style="width:27px"> </div></td>430<td class="c4">(1.00x baseline)</td></tr>431</table>432<h4>Random Reads</h4>433<table class="bn">434<tr><td class="c1">LevelDB</td>435<td class="c2">149,000 ops/sec</td>436<td class="c3"><div class="bldb" style="width:300px"> </div></td>437<td class="c4">(1.16x baseline)</td></tr>438<tr><td class="c1">Kyoto TreeDB</td>439<td class="c2">175,000 ops/sec</td>440<td class="c3"><div class="bkct" style="width:350px"> </div></td>441<td class="c4">(1.16x baseline)</td></tr>442<tr><td class="c1">SQLite3</td>443<td class="c2">134,000 ops/sec</td>444<td class="c3"><div class="bsql" style="width:268px"> </div></td>445<td class="c4">(1.00x baseline)</td></tr>446</table>448<p>Performance of both LevelDB and TreeDB improves a small amount when449compression is disabled. Note however that under different workloads,450performance may very well be better with compression if it allows more451of the working set to fit in memory.</p>453<h2>Note about Ext4 Filesystems</h2>454<p>The preceding numbers are for an ext3 file system. Synchronous writes are much slower under <a href="http://en.wikipedia.org/wiki/Ext4">ext4</a> (LevelDB drops to ~31 writes / second and TreeDB drops to ~5 writes / second; SQLite3's synchronous writes do not noticeably drop) due to ext4's different handling of <span class="code">fsync</span> / <span class="code">msync</span> calls. Even LevelDB's asynchronous write performance drops somewhat since it spreads its storage across multiple files and issues <span class="code">fsync</span> calls when switching to a new file.</p>456<h2>Acknowledgements</h2>457<p>Jeff Dean and Sanjay Ghemawat wrote LevelDB. Kevin Tseng wrote and compiled these benchmarks. Mikio Hirabayashi, Scott Hess, and Gabor Cselle provided help and advice.</p>458</body>459</html>
Independent explanations by MyBitcoinExplorer. Not affiliated with or endorsed by Bitcoin Core. Guides are educational and do not replace the source or its tests.
Bitcoin Core source © its contributors, distributed under the MIT license. Original notices and bundled third-party licenses are retained in the source tree.