<blockquote>
  <p>Does running bitcoind with -prune option make the initial blockchain
  sync faster or not?</p>
</blockquote>

<p>No, it just allows you to define the maximum storage space for old blocks to use, but it will still download all of the blocks to verify them, deleting them afterwards.</p>

<pre><code>-prune=&lt;n&gt;
     Reduce storage requirements by enabling pruning (deleting) of old
     blocks. This allows the pruneblockchain RPC to be called to
     delete specific blocks, and enables automatic pruning of old
     blocks if a target size in MiB is provided. This mode is
     incompatible with -txindex and -rescan. Warning: Reverting this
     setting requires re-downloading the entire blockchain. (default:
     0 = disable pruning blocks, 1 = allow manual pruning via RPC,
     &gt;=550 = automatically prune block files to stay under the
     specified target size in MiB)
</code></pre>

<p>To reduce the sync time you could use the <code>-assumevalid</code> flag to move the default assumed valid block to a later block, but obviously this is a risk you take.</p>

<pre><code>-assumevalid=&lt;hex&gt;
       If this block is in the chain assume that it and its ancestors are valid
       and potentially skip their script verification (0 to verify all,
       default:
       0000000000000000005214481d2d96f898e3d5416e43359c145944a909d242e0,
       testnet:
       0000000002e9e7b00e1f6dc5123a04aad68dd0f0968d8c7aa45f6640795c37b1)
</code></pre>

CC BY-SA 4.0
2018-09-26T23:49:21.900Z
Moving assume valid to an _earlier_ block will make the sync slower, not faster.  Unless you are running a really old version it's unlikely that you can speed things up substantially by changing it at all.
G. Maxwell
CC BY-SA 4.0
2018-09-26T03:42:56.190Z
2018-09-27T01:24:59.670Z
2018-09-27T01:24:59.670Z
JBaczuk
<p>Pruning won't make your initial sync faster.</p>

<p>I know how painful for an HDD user to sync a full node...</p>

<p>If you have SSD, just use it. You may configure the blocksdir parameter to migrate the gigantic block storage to inexpensive HDD.</p>

<p>There is also an ugly trick to significantly acclerate the initial sync: use RAMDisk/tmpfs to store the chainstate subdirectory. In some more detail, NTFS junction(Windows)/symbolic link(Linux or Mac) could be used to redirect the path, while ImDisk(Windows)/tmpfs(Linux/Mac) could provide the RAMDisk.</p>

<p>A trick which is less ugly also exists: use type(Windows CMD)/cat(Linux/Mac) command to read all files in chainstate subdirectory before starting the full node, so that the OS would load these files into cache. This trick is more useful when you are catching up from several days ago.</p>

CC BY-SA 4.0
2019-01-14T20:38:45.950Z
It's much better to increase your dbcache than to use a RAM disk.
Pieter Wuille
CC BY-SA 4.0
2019-01-14T20:47:28.390Z
But HDDs are incredibly slow. It's so slow that the user may be willing to accept the downsides of a RAMDisk. Despite whether RAMDisk could help the initial sync more than larger dbcache, an ugly manual "preheat" in deed helps the full node to catch up.
Chris Chen
CC BY-SA 4.0
2019-01-14T21:37:49.810Z
You miss my point. If you make the database cache large enough, the node won't need any disk I/O for validation. That's more efficient than using a RAMdrive to accomplish the same thing.
Pieter Wuille
CC BY-SA 4.0
2019-01-14T22:12:29.537Z
How much RAM is required for this goal? Is 4GB enough? I've seen people accomplish this goal with a RAMDisk of 4GB.
Chris Chen
CC BY-SA 4.0
2019-01-22T23:22:29.880Z
@PieterWuille I once monitored bitcoin-qt.exe with procexp. It turned out that setting dbcache to 4GB is not enought, since I/O operations were continuously emitted after the cache became full.
Chris Chen
CC BY-SA 4.0
2019-01-23T01:21:11.107Z
Yes, you need around 6GB I believe to avoid flushing entirely. But with 4GB it should already be pretty rare.
Pieter Wuille
CC BY-SA 4.0
2019-01-23T01:58:28.190Z
@PieterWuille Although chainstate was not frequently written with 4GB dbcache, resource monitor showed that bitcoin-qt.exe was still intensively emitting random read operations on chainstate.
Chris Chen
CC BY-SA 4.0
2019-01-14T20:33:55.360Z
2019-01-14T20:33:55.360Z
Chris Chen
<p>No, pruning will not make the initial sync faster. The information that gets removed by pruning isn't accessed turning the initial sync.</p>

<p>Currently pruning makes the initial sync somewhat slower: more frequent flushes are performed in order to allow pruning to work, and the work of actually deleting things creates its own small slowdown. About the same is probably a fair statement in general.</p>

<p>The only configuration which can substantially speed up the initial sync is increasing the dbcache option.  If you have plenty of memory (e.g. >4GB) making this setting larger can radically reduce the sync time, esp. if your disk is slow. For 8GB ram I recommend setting dbcache=4096 during the initial sync. </p>

CC BY-SA 4.0
2018-09-27T04:53:15.063Z
Great tip on the dbcache flag
JBaczuk
CC BY-SA 4.0
2018-09-26T03:41:14.263Z
2018-09-26T23:51:48.007Z
2018-09-26T23:51:48.007Z
G. Maxwell
<p>Does running bitcoind with <code>-prune</code> option make the initial blockchain sync <em>faster</em> or not? I know it makes it smaller on disk, but is it faster?</p>

<p>I keep reading conflicting information online - some state that it is quicker because you need less disk operations, some state it is about the same.</p>

<bitcoind><pruning>
Does running pruning node make the initial sync faster?
Karel Bílek
# Does running pruning node make the initial sync faster?

(Asked by: username_0 on 2018-09-26)

Does running bitcoind with `-prune` option make the initial blockchain sync *faster* or not? I know it makes it smaller on disk, but is it faster?

I keep reading conflicting information online - some state that it is quicker because you need less disk operations, some state it is about the same.

**Tags:** bitcoind, pruning


---

## 3 answers

### Answer by username_2 on 2018-09-26. Score: 12 | Accepted answer

No, pruning will not make the initial sync faster. The information that gets removed by pruning isn't accessed turning the initial sync.

Currently pruning makes the initial sync somewhat slower: more frequent flushes are performed in order to allow pruning to work, and the work of actually deleting things creates its own small slowdown. About the same is probably a fair statement in general.

The only configuration which can substantially speed up the initial sync is increasing the dbcache option. If you have plenty of memory (e.g. >4GB) making this setting larger can radically reduce the sync time, esp. if your disk is slow. For 8GB ram I recommend setting dbcache=4096 during the initial sync.

> **Comments:**
> **username_1**: Great tip on the dbcache flag  

---

### Answer by username_1 on 2018-09-26. Score: 4

> Does running bitcoind with -prune option make the initial blockchain
> sync faster or not?

No, it just allows you to define the maximum storage space for old blocks to use, but it will still download all of the blocks to verify them, deleting them afterwards.

```
-prune=<n>
     Reduce storage requirements by enabling pruning (deleting) of old
     blocks. This allows the pruneblockchain RPC to be called to
     delete specific blocks, and enables automatic pruning of old
     blocks if a target size in MiB is provided. This mode is
     incompatible with -txindex and -rescan. Warning: Reverting this
     setting requires re-downloading the entire blockchain. (default:
     0 = disable pruning blocks, 1 = allow manual pruning via RPC,
     >=550 = automatically prune block files to stay under the
     specified target size in MiB)

```

To reduce the sync time you could use the `-assumevalid` flag to move the default assumed valid block to a later block, but obviously this is a risk you take.

```
-assumevalid=<hex>
       If this block is in the chain assume that it and its ancestors are valid
       and potentially skip their script verification (0 to verify all,
       default:
       0000000000000000005214481d2d96f898e3d5416e43359c145944a909d242e0,
       testnet:
       0000000002e9e7b00e1f6dc5123a04aad68dd0f0968d8c7aa45f6640795c37b1)

```

> **Comments:**
> **username_2**: Moving assume valid to an _earlier_ block will make the sync slower, not faster.  Unless you are running a really old version it's unlikely that you can speed things up substantially by changing it at all.  

---

### Answer by username_3 on 2019-01-14. Score: 0

Pruning won't make your initial sync faster.

I know how painful for an HDD user to sync a full node...

If you have SSD, just use it. You may configure the blocksdir parameter to migrate the gigantic block storage to inexpensive HDD.

There is also an ugly trick to significantly acclerate the initial sync: use RAMDisk/tmpfs to store the chainstate subdirectory. In some more detail, NTFS junction(Windows)/symbolic link(Linux or Mac) could be used to redirect the path, while ImDisk(Windows)/tmpfs(Linux/Mac) could provide the RAMDisk.

A trick which is less ugly also exists: use type(Windows CMD)/cat(Linux/Mac) command to read all files in chainstate subdirectory before starting the full node, so that the OS would load these files into cache. This trick is more useful when you are catching up from several days ago.

> **Comments:**
> **username_4**: It's much better to increase your dbcache than to use a RAM disk.  
> **username_3**: But HDDs are incredibly slow. It's so slow that the user may be willing to accept the downsides of a RAMDisk. Despite whether RAMDisk could help the initial sync more than larger dbcache, an ugly manual "preheat" in deed helps the full node to catch up.  
> **username_4**: You miss my point. If you make the database cache large enough, the node won't need any disk I/O for validation. That's more efficient than using a RAMdrive to accomplish the same thing.  
> **username_3**: How much RAM is required for this goal? Is 4GB enough? I've seen people accomplish this goal with a RAMDisk of 4GB.  
> **username_3**: @username_4 I once monitored bitcoin-qt.exe with procexp. It turned out that setting dbcache to 4GB is not enought, since I/O operations were continuously emitted after the cache became full.  
> **username_4**: Yes, you need around 6GB I believe to avoid flushing entirely. But with 4GB it should already be pretty rare.  
> **username_3**: @username_4 Although chainstate was not frequently written with 4GB dbcache, resource monitor showed that bitcoin-qt.exe was still intensively emitting random read operations on chainstate.  

---

