I agree this needs to be improved, and I agree there should be a splash screen or a disabled GUI while things load. It would seem that you could store temporary information from the last time the client was closed, to display at startup but gray-out the send-money button. Then the user can browse the previous transaction data, create new addresses, etc, while the backend goes through and re-verifies the blockchain. You could even put the progress bar under the "send" button to show the user why it's grayed out. This should solve a lot of the current speed problems if the multithreading can be done correctly (don't ask me to do it, I've never written MT code).
But, I've been thinking a lot about it how to optimize the file-reading and I'm working a prototype right now. Unfortunately, it is without much context about what is already there in the client code, but this is fun for me so I'm working on the ultimate-efficiency blockchain file-loading. I'd like to hear any thoughts on this process...
By my calculation, we have about 400 MB of blockchain information, which for most HDDs should take about 5 seconds to read. That means, at least while the client is designed to maintain the entire blockchain, we'll never beat 5 seconds load time for the average user. This may not be too bad right now, but it's not going to get any better. And of course, it takes a lot longer than that because the blockchain has to be processed/verified as it is read in. My thought is... what if it doesn't take any extra time?
- (1) The blockchain data is stored in the file in exactly the same binary format as would be stored in RAM.
- (2) In memory, allocate 400 MB of storage behind a raw uint8_t pointer
- (3) Do a direct copy "blk0001file.read(ramChunkPtr, fileSize)"
- (4) Use BlkHeaderPtr and TxPtr objects -- the members are pointers to locations in this chunk of memory instead of copies
- (5) Write the accessor methods to simply dereference the pointers, any time
The overhead of storing these pointers should be small compared to the blockchain itself. And there's two options for assigning the pointers... either walk through the data and assign them manually (which would be slowed slightly be all the var_ints), or store the variable byte-locations in another file, (known from the last client shutdown). Hell, you could do the exact same memory chunk idea with this file, but even faster because they are all constant-width fields (and dramatically less data). Either way, this should be about the best time-efficiency possible, paid for with a slight reduction in space efficiency.