I have tried both building 0.5.3 myself and using the pre-compiled 0.5.1 binaries. The results are the same: the clients are totally unusable.
The CLI client of both versions still has the unbearable typing lag I mentioned last time. Running it with --server and using the web wallet doesn't help. It is very slow. The RPC POST requests have an average latency of around 2 minutes and some of them timeout with an error!
The Qt client isn't better. The 0.5.3 Qt client is very slow and laggy and sometimes won't ever load pages like the market. In fact it completely froze my Ubuntu system (hard reset required) when I tried to load the market in an attempt to cover a short! The performance of the 0.5.1 Qt client was actually pretty decent, but I quickly realized the only reason that was the case was because the blockchain wasn't syncing at all beyond the point left by the CLI client (a problem I mentioned last time with v0.4.27.2), meaning its completely worthless.
So basically there is no properly functioning client for me at the moment. I only have 4 GB of RAM on the laptop so I didn't expect super snappy performance with the full client, but this is just ridiculous. It has to be some bug in the client right? Or is my computer somehow messed up?
Please let me know if these performance problems are still present in 0.6.0.
The blockchain replay on initial start of v0.6.0 of bitshares_client took a pretty long time (specifically, it took 12931 seconds to replay 1643284 blocks, or an average rate of 127 blocks/second) but at least it wasn't too taxing on my computer which allowed me to comfortably multitask. But this was only up to the block as of 10 days ago (last time I synced the BitShares blockchain).
So then I let the client sync the remaining 10 days of blocks. During this time it was taxing my computer noticeably more than during replay but it was still okay for multitasking [1]. However, bitshares_client was experiencing the horrible typing lag (this is with the wallet closed). The remaining syncing took approximately 110 minutes, so that was another 1735192-1643284=91908 blocks in roughly 6600 seconds, which is an average of 14 blocks/second. That average rate is significantly smaller than the 127 blocks/second replay rate, but to be fair the replay rate was an average over many blocks and I did notice that the instantaneous replay rate significantly slowed over time (meaning the syncing rate seems to get worse as the blockchain/database evolves over time). The typical IO usage during this syncing process was roughly 7 MB/s disk read and roughly 200 KB/s disk write (although towards the last few days worth of blocks that it was syncing the write rate had dropped to somewhere around 75 KB/s).
Actually, what was interesting is that the client never really synced. It reached close to the head block but was always 10 to 20 seconds behind. The typing lag remained. The virtual memory usage was above 5.5 GB and the resident memory usage was about 2 GB. And it was still heavily taxing my computer. So, I closed bitshares_client and then restarted.
When bitshares_client started up again, it exhibited no typing lag and I was able to see that it was 4 minutes behind. Within a few seconds, it synced to the present head block (< 10 seconds behind). It again still exhibited no typing lag. It was able to keep the blockchain in sync while barely taxing the computer. During this time the disk read usage was typically around 5 MB/s and the disk write usage was typically under 10 KB/s. The initial memory usage was a little over 2 GB in virtual memory, a little over 600 MB in resident memory, and a little over 200 MB in shared memory. This is all with the wallet still closed.
Then, I unlocked the wallet. The wallet scanning finished quickly. Everything was still running smoothly. No typing lag, no trouble maintaining sync. The
previous problem I had reported seems to be solved (
thanks Vikram!).
So, what I have learned from this is that there was a performance bug with the client when the wallet is unlocked that existed in 0.5.3 and was solved with 0.6.0, that the client still has a lot of trouble initially syncing the blockchain to the present after being offline for a while (at least on my computer with 4 GB of RAM and a HDD), and that the blockchain syncing gets significantly worse over time and the client uses more and more memory (seemingly unnecessarily) which is why it probably makes sense to restart the client after some amount of syncing in those cases so that it can start fresh. It also suggests to sync the blockchain more frequently (I guess I need to make it a habit to sync the blockchain once a day even when I have no use for it).
[1] This is not entirely true. First, I noticed that the memory usage of bitshares_client steadily increased over time (resident memory had grown over 2 GB near the end of the sync; virtual memory was over 5.5 GB). At some point during the syncing process, Chrome (which I was using at the time) started using the disk a lot too (maybe because RAM became even more scarce than normal?) and that combined with the IO usage of bitshares_client seems to have really brought my computer to its knees. I wasn't able to investigate carefully because I was just trying to fix the problem before I would be forced into hard resetting the computer. There was a period of time (several minutes) where the entire computer GUI was frozen so badly and it took me minutes to just switch to a console to type the command "killall chrome" and regain usable control of my computer. The conclusion I am reaching is that I cannot actually both run Chrome and sync the blockchain to the present after a long time of being offline using bitshares_client at the same time on my computer. : (