-
Notifications
You must be signed in to change notification settings - Fork 38.7k
tests: speed up coinselector_tests #23338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
cc @jnewbery |
Instead of using AddToWallet so that making a COutput will work, directly add the transaction into wallet.mapWallet. This bypasses many checks that AddToWallet will do which are pointless and just slow down this test.
Default to SQLiteDatabase instead of BerkeleyDatabase for CreateDummyWalletDatabase. Most tests already use descriptor wallets and the mock db doesn't really matter for tests. The tests where it does matter will make the db directly.
d00afd2 to
a52f1d1
Compare
brunoerg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tACK a52f1d1
Ran the test on the master branch, it didn't take over 1 minute here, took about 30secs, but now it is taking ~3 seconds. (Macbook M1)
lsilva01
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tACK a52f1d1. Performed 74.36% better on Ubuntu 20.04 (VM, 12 MB, 8vCPU).
glozow
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK a52f1d1
Since it's a coin selection unit test and add_coin's job is to populate the coins vector with UTXOs to select from, calling mapWallet.emplace() directly seems sensible. I don't know this code very well but AFAICT none of the coin selection functions rely on the something done in AddToWallet. On my machine, the test sped up from 33sec to 3sec.
Side note: the AddToWallet function declaration is missing a doxygen comment. It would be nice to add one.
a52f1d1 walletdb: Use SQLiteDatabase for mock wallet databases (Andrew Chow) a78c229 tests: Place into mapWallet in coinselector_tests (Andrew Chow) Pull request description: bitcoin#23288 changed coinselector_tests to use `DescriptorScriptPubKeyMan`, but it also ended up significantly slowing down the test, from 4 seconds to over 1 minute. It appears that the source of this slow down is with `CWallet::AddToWallet`, and primarily due to writing data to the mock wallet database. Because the only thing that is actually needed is for the created transaction to be placed into `CWallet::mapWallet`, this PR removes the call to `AddToWallet` and just places the transaction into `mapWallet` directly. This reduces the test time to 5 seconds. To speed things up further, `CreateMockWalletDatabase` is changed to make a `SQLiteDatabase` instead of a `BerkeleyDatabase`. This is safe because there are no tests that require a specific mock database type. ACKs for top commit: brunoerg: tACK a52f1d1 lsilva01: tACK a52f1d1. Performed 74.36% better on Ubuntu 20.04 (VM, 12 MB, 8vCPU). glozow: utACK a52f1d1 Tree-SHA512: da77936bfd2e816d2e71703567b9389d0ee79f3a4a690802ffe3469df5bed371b296cb822b897f625654dab9436d91fd6bc02364a518a47d746e487d70a72595
#23288 changed coinselector_tests to use
DescriptorScriptPubKeyMan, but it also ended up significantly slowing down the test, from 4 seconds to over 1 minute. It appears that the source of this slow down is withCWallet::AddToWallet, and primarily due to writing data to the mock wallet database. Because the only thing that is actually needed is for the created transaction to be placed intoCWallet::mapWallet, this PR removes the call toAddToWalletand just places the transaction intomapWalletdirectly. This reduces the test time to 5 seconds.To speed things up further,
CreateMockWalletDatabaseis changed to make aSQLiteDatabaseinstead of aBerkeleyDatabase. This is safe because there are no tests that require a specific mock database type.