Skip to content

Conversation

@achow101
Copy link
Member

@achow101 achow101 commented Oct 22, 2021

#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.

@achow101
Copy link
Member Author

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.
Copy link
Contributor

@brunoerg brunoerg left a 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)

Copy link
Contributor

@lsilva01 lsilva01 left a 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).

Copy link
Member

@glozow glozow left a 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.

@maflcko maflcko merged commit b9cf505 into bitcoin:master Oct 25, 2021
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Oct 25, 2021
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
@bitcoin bitcoin locked and limited conversation to collaborators Oct 30, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants