4
You are allocating far too much dbcache. If you allocate 4000 MB to the dbcache, you will use up all of your RAM and it will crash. Your operating system needs RAM, Bitcoin Core itself needs RAM outside of the dbcache. I would highly recommend that you do not set a dbcache at all as 4 GB is really not enough RAM to handle a larger dbcache, Bitcoin Core's ...
4
The UTXO set cache is not a fixed size and the limit isn't a hard limit. New entries can be added to the cache without regards for the maximum cache size. In fact, the cache object itself doesn't even know what the limit is.
Rather what happens is that the cache is flushed periodically. Because the UTXO set only changes during block validation (mempool UTXO ...
3
The signature cache is basically a set of public key, message hash, and signature tuples. When there is a valid pubkey, message hash, and signature combination, all of those are hashed together with SHA256. This hash is then inserted into the signature cache. So the signature cache contains only the hashes of valid combinations. When verifying a signature, ...
3
dbcache is the only significant performance influencing option. Performance may be improved somewhat by increasing receive and send buffer sizes.
You don't specify exactly what application's you're concerned with speeding up. To lower block reception latency you could connect to matt's public fibre network. See http://bitcoinfibre.org/public-network.html
2
The Bitcoin Core documentation describes dbcache as the cache for the UTXO database.
Wikipedia describes a cache as a:
software component that stores data so that future requests for that data can be served faster; the data stored in a cache might be the result of an earlier computation or a copy of data stored elsewhere.
Greg Maxwell added on IRC:
There ...
2
The block index and chain state databases are LevelDB databases. LevelDB has its own caching and cache management. So 2 MiB is being allocated for the block index's LevelDB database cache, and 8 MiB is being allocated for the chain state's LevelDB database cache.
However Bitcoin Core does additional caching by itself, particularly for the UTXO set, which is ...
1
Will Clark answered this question on IRC.
You can reduce the time it takes to run ./configure by using ./configure -q -C. -q is quiet and -C removes terminal printing and uses a cache (like ccache). It reduced Will's configure time from 29 seconds to 10 seconds. For more details see this info page.
1
The tool ccache helps store intermediate compilation results, so if you changes branches often, and rebuild, it can significantly speed up doing so.
To use it, you install ccache for your platform. That's it. The Bitcoin Core configure script will detect its presence, and use it automatically.
Only top voted, non community-wiki answers of a minimum length are eligible