user1760: 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.

user60443: 
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)


user52021: 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. 

1760: <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>
 60443: <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>
 52021: <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>
