The issue of high CPU usage has been explained already by danbi. Not sure we can do anything more than that right now. Wallet 2.0.3.2 is being tested at the moment.
About hight CPU usage.
I am currently hacking the next wallet version, with the specific focus to cure the dreaded block index corruption issue (already found out the reason).
However, during testing and some measurements, it seems the wallet is doing some 12 calculations of the block hash for each block it receives from the network (this, considering 2.0.3.1 already has eliminated some of these!). These hash calculations are always expensive.
In minting mode, the wallet would periodically traverse over the list of coin 'piles' it has, as well as all the addresses it has in the wallet. As it turns out, the Bitcoin design and therefore inherited by almost all other coins is to create a new address for the 'change' (the remainder, when you send coins). This is done to 'guarantee' anonymity, although what is achieved is questionable, because anyone with the full block chain can track this, of course. The sad side effect is your wallet gets bloated more and more, as you send out coins.
So if you have had many outgoing transactions, you will have lots of very small coin piles and (unfortunately) many addresses (public/private key pairs) in the wallets, most of which would have zero balance. In Diamond, PoS would naturally work to group those small coin piles (including dust) into larger piles, but unfortunately, it will not eliminate the addresses..
Some of the next Diamond wallets will have a feature to handle that, if the uses so wishes. That will help greatly busy wallets, such as pools and exchanges. In mean time, you could help yourself -- for new transactions only -- by utilizing the 'change address' feature of Coin Control -- when you send out Diamonds.
What all this means in essence is, that you will get much better performance, if you separate your 'savings' and 'spending' wallets. Only send coins to the 'savings' wallet and let it mint, and do not send out coins out of it -- if you do, use Coin Control to direct the change to your own address.
If you already suffer from too much bloat, about the only possible workaround is this:
of course, make a backup of your wallet.dat first
check to see which addresses have coins with listaddressgroupings
dump the private keys (with dumpprivkey) for each address which you have given out to others to send you coins AND all addresses you identified have coins in the previous step.
stop the wallet
move the old wallet.dat out of the way
start the wallet
import all the private keys with importprivkey (this will rescan the block chain for each one)
enjoy your faster wallet.
On the high CPU usage again.
Normally, without any special configuration, the wallet will try to participate as much as possible in the Diamond network. This is of course good thing and is encouraged.
However, combined with the conditions described in my previous post, this might further increase the CPU load.
Consider this: the wallet has by default limit of 125 connections to peers. When a peer sends you a new block, you do some 12 hashes of it in various check routines (at the moment, working on it). It is very much possible that multiple peers will send you the same block at about the same time -- you will ignore all but the first, but will do the processing nevertheless.
In addition, when a peer asks you for blocks to sync (any wallet will ask any and all other wallets it is connected with about blocks it doesn't yet have) you are sending them streams of 500 blocks at a time. You do some processing around selecting those blocks and transmitting them. There may be several peers asking for blocks as the same time.
If you would like to ultimately reduce your CPU usage while minting, you can restrict your participation in the network topology. This topic is sufficiently discussed in the thread, but in short, for least load, you should have
connect=somereliablenode
connect=someothernode
listen=0
noirc=1
If you look back in the thread, this was a suggested configuration for nodes that generate blocks, like when you mint.
If on the other hand, you don't mind the CPU load, you are welcome to let your node fully participate in the network.
