The first secure, decentralized, human-meaningful naming system.
https://forum.namecoin.org/
i mean it need to check for them to put them in the gui? - am probably wrongphelix wrote:Hmm there should not have been any incoming transfers on that wallet... some ever pending ones, though.snailbrain wrote:
I apologise if this is not relevant.. but something about incoming transfer of names in the qt is ringing some bells..
I do not know if this theory is correct, but if it is, then the problem is common to namecoin and bitcoin. If so, it would make sense to address "upstream", i.e. in the bitcoin codebase.domob wrote:each block from which some transaction uses an output has to be read from disk - and this produces lots of random accesses to the blockchain files.
Not entirely, since Bitcoin stores the blockchain no longer in the unstructured files but instead in a LevelDB. This possibly takes care of proper caching. (But I don't know the respective pieces of the Bitcoin code.) This makes the problem less severe than for Namecoin, so that it is acceptable at the moment for most users.crosser wrote:I do not know if this theory is correct, but if it is, then the problem is common to namecoin and bitcoin. If so, it would make sense to address "upstream", i.e. in the bitcoin codebase.domob wrote:each block from which some transaction uses an output has to be read from disk - and this produces lots of random accesses to the blockchain files.
Have you actually tried this and does dbcache=1500 remove the disk accesses? Does it give good performance on a non-SSD system? Note that, as mentioned above, the blockchain itself is not stored in BDB. Thus also dbcache should not have an effect on it. Instead, for each tx output that is checked in ConnectInputs, the respective tx is loaded from disk (as far as I can tell from the code). While the dbcache will help with accesses to blkindex.dat, I doubt that it actually speeds up transaction verification. This is why I propose to move the full UTXO set to a BDB file, not just the tx index.phelix wrote:Hmm dbcache=1500 things should not be limited by random disk access too much. Also on SSD systems things are somehow slowed down with GUI and a large wallet.
I will take look at that mutex locking issue.
Back then I merged a patch from Bitcoin to allow to change the dbcache size. I am quite certain that it helped considerably on the non-SSD system I tested it on. Other optimizations where about less flushing of the db files.domob wrote:Have you actually tried this and does dbcache=1500 remove the disk accesses? Does it give good performance on a non-SSD system? Note that, as mentioned above, the blockchain itself is not stored in BDB. Thus also dbcache should not have an effect on it. Instead, for each tx output that is checked in ConnectInputs, the respective tx is loaded from disk (as far as I can tell from the code). While the dbcache will help with accesses to blkindex.dat, I doubt that it actually speeds up transaction verification. This is why I propose to move the full UTXO set to a BDB file, not just the tx index.phelix wrote:Hmm dbcache=1500 things should not be limited by random disk access too much. Also on SSD systems things are somehow slowed down with GUI and a large wallet.
I will take look at that mutex locking issue.
Code: Select all
// Flush stdio buffers and commit to disk before returning
fflush(fileout);
if (!IsInitialBlockDownload() || (nBestHeight+1) % 500 == 0)
{
#ifdef __WXMSW__
_commit(_fileno(fileout));
#else
fsync(fileno(fileout));
#endif
}
In theory, probably. But for Huntercoin, it makes an order of magnitude difference to move the blockchain directory to a RAM disk before syncing, and back after that. I've not explicitly tried it out with Namecoin, but it is probably the same.phelix wrote:With reading from a non-BDB file should not the system cache take care of the random reads (at least at initial blockchain download and given enough RAM).
Have you tried the locking patch? Does it help? For me, syncing the Namecoin blockchain always was somewhat painful and slow even though I never run the Namecoin-UI. Just running Namecoin in the background (and syncing a day's worth of blocks or so) is usually fine, though.phelix wrote:Anyway, the issue I see on my machine certainly is GUI related. I could not yet figure out how to get around it.
with mechanical harddisk:domob wrote:In theory, probably. But for Huntercoin, it makes an order of magnitude difference to move the blockchain directory to a RAM disk before syncing, and back after that. I've not explicitly tried it out with Namecoin, but it is probably the same.phelix wrote:With reading from a non-BDB file should not the system cache take care of the random reads (at least at initial blockchain download and given enough RAM).
Have you tried the locking patch? Does it help? For me, syncing the Namecoin blockchain always was somewhat painful and slow even though I never run the Namecoin-UI. Just running Namecoin in the background (and syncing a day's worth of blocks or so) is usually fine, though.phelix wrote:Anyway, the issue I see on my machine certainly is GUI related. I could not yet figure out how to get around it.