rich1.0npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6hhttps://nostr.ae/npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6hnjumphttps://nostr.ae📅 Original date posted:2012-02-01 📝 Original message:Hi Gregory, I played with the database sync as well to get further speedups, but in the latest version I could only get about 1% extra from this. In the Satoshi client there is a bunch of sleeps and mutexes (put in there with great generosity) for making threads run smoother and to avoid deadlock I guess. The big change in speed came from moving from the threading based setup to the async based setup, so I think these are the culprit. Further, as I also write somewhere in the wiki. I can measure that 50% of the time is consumed in verify, so there is not much left to optimize now. Actually, Berkeley DB does a quite decent job in caching reads so not even a cache should help. Cheers, M On 01/02/2012, at 15:59, Gregory Maxwell wrote: > On Wed, Feb 1, 2012 at 9:18 AM, Michael Grønager <gronager at ceptacle.com> wrote: >> The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop! > > Very interesting. Do you know where this speedup came from? It's not > typical for straight refactors that don't change datastructures and > the like to see such big speedups. > > I see you have commented out code that disables fsync, which was my > first guess since I get big speedups from doing similar things. Michael Gronager, PhD Director, Ceptacle Jens Juels Gade 33 2100 Copenhagen E Mobile: +45 31 45 14 01 E-mail: gronager at ceptacle.com Web: http://www.ceptacle.com/