Tweaks

On this page you can find ways to improve performance and lower resource consumptions of a running client.
Like with every tuning, you should apply any changes in steps, checking each time for expected gains.
In particular, you should monitor your system for RAM usage. If it uses all the memory, revert the change before you see the swap file burning.

Note: If you experience problems and don't know why, just go back to the default config.
To restore the default config, simply delete gocoin.conf and execute client -sc to recreate it.

Garbage Collector and UTXO heap

If you have RAM to spare, try increasing the Garbage Collector treshold, from the default value.
This will increase memory usage, but should improve performance (e.g. initial blockchain download time).
For that, edit the config file to set Memory.GCPercTrshold to double, tripple or even more (higher value for more effect).

Alternativelly, you can turn off the GC treshold (by setting it to -1) and control the maximum memory usage via Memory.MemoryLimitMB.
Use this method if you want to allocate a fixed amount of RAM for your running node (it will use all the memory given).

Additionally, you can switch UTXO records to Go's native heap manager by setting Memory.UseGoHeap to true.
This seems to significantly improve UTXO update performance (so also chain sync times), as long as your node does not run GC too often.
At the other hand, your node will then need more memory and loading of UTXO database (when node starts) will take slightly longer.

Initial chain sync cache

If you have a fast internet connection (e.g. 1Gbit), examine the two options listed below.
Don't bother with a slow connection, as the download speed is your bottleneck then (it's when a syncing node uses your entire bandwidth).

However, with a fast network the bottleneck is the speed at which your node builds the UTXO database.
To assure the UTXO worker doesn't have to wait for the network, the node tries to download blocks ahead and store them in the cache.
The bigger the cache, the less likely it is that the UTXO worker will ever be idle, having to wait for the network.

Here are the two options - the first one will likely have a better effect on the performance (but requires more RAM):

Turn off caching on disk. Edit the config file and set the value of Memory.CacheOnDisk to false.
Increase cache size. Edit the config file and increase the value of Memory.SyncCacheSize.

Mind that with CacheOnDisk disabled, a change of the cache size has a major effect on memory usage.
Make sure your client is not using all available RAM, or the sync performace will tank instead of improving.

At the other hand, having the cache on disk results in a minimal memory requiement even for a huge cache size.
But it comes at the extra time required for the disk operations and re-creation of memory structures after loading.

Note:
1. This only affects the chain sync performance. Once the chain is synchronized, it does not matter.
2. Monitor your node's TextUI for cachempty: X debugs. If X is not increasing after block 200000, don't bother with a bigger cache.
3. The node does not need restarting to apply new values of these parameters.
4. Restarting the node during chain sync discards the entire cache, even when on disk.

Disable wallet functionality

You can disable node's wallet functionality, to save system memory used by a running client and improve block processing times.
In order to do so, use TextUI command wallet off or click the disable wallet button on the bottom of the Wallet page in the WebUI.
Note: This is only applicable to a synchronized node - after it launched and made sure to have all the recent blocks.

If you don't want the wallet functionality to automatically enable after the node is started and synchronized, set the value of AllBalances.AutoLoad to false in the config file.
Note: You can manually enable wallet functionality at any time while the node is running, either from WebUI or by executing TextUI command wallet on.

External secp256k1 speedups

It is possible to use libsecp256k1 (maintained by Bitcoin Core project) that is written in C and assembler.
Note: To check the performance difference, use test programs from gocoin/lib/others/cgo/ec_bench/ (e.g. go run gonative.go vs go run sipasec.go).

To make Gocoin client to use the external library, copy either the file sipadll.go (Windows only) or sipasec.go (any OS), from gocoin/client/speedups/ to its parent folder (gocoin/client/). Then rebuild and restart the client.
Note: You can have either sipadll.go or sipasec.go in your gocoin/client/ folder, but never both of them as the client will not build then.

Depending which speedup file you chose, follow either of the instructions in the table below.

sipasec.go sipadll.go (Windows only)

In order to use sipasec.go speedup, build and install secp256k1 library in your system.

On Debian based Linux system, simply execute the following commands:
sudo apt-get install gcc automake autoconf libtool make git libgmp-dev
git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin/src/secp256k1/
./autogen.sh
./configure
make
sudo make install

Note: When the library is properly installed, executing go test inside gocoin/lib/others/cgo/sipasec/ says PASS. To use sipadll.go speedup, you have to place secp256k1.dll in gocoin/client/ or in any folder where Windows looks for executables (e.g. C:\WINDOWS).

You can find secp256k1.dll in gocoin/tools/sipa_dll/ or you can download it from sourceforge.net (it's inside secp256k1.dll_v2-amd64.zip).

To build secp256k1.dll youself, look into secp256k1_win_v2.zip.

Disable BlockDB compression

Edit the config file and set the value of Memory.CompressBlockDB to false.
This may improve chain sync performance, as well as some tasks of a synchronized node.

However, it will require more disk storage, as the compression saves about 15% of blocks data space.

Compress UTXO records

To save some system memory as well as a disk space, although at the cost of a performance, you can compress UTXO database.

In order to do this, execute the tool utxo -compress.
The tool needs to be executed from inside the data folder - where the UTXO.db file is.
The node must not be running while executing the tool.

You can reverse the operation of compressing the database, be running utxo -decompress.

Note: It saves only about 3% of space used by UTXO.db file and evel less RAM.

Compiler optimizations

Building the client (with go build), set GOAMD64 variable to the highest value supported by your CPU.
Most CPUs will work with GOAMD64=v3 and the latest models support GOAMD64=v4

There is also an experimental Garbage Collector engine, which you can enable be setting GOEXPERIMENT=greenteagc

Disable counters

Edit the config file and set the value of Stats.NoCounters to true.
This will turn off node's internal statistics which should improve performance.

Note: It is likely that such a performance gain will not be noticable.