Skip to content

Conversation

maflcko
Copy link
Member

@maflcko maflcko commented Apr 23, 2021

Locally the test will run 4 seconds faster with --valgrind (18s vs 14s)

MarcoFalke added 4 commits April 22, 2021 20:02
Can be reviewed with --ignore-all-space --color-moved=dimmed-zebra
The documentation did not match the implementation, no coins
were mined to the OP_TRUE address.
@fanquake fanquake added the Tests label Apr 23, 2021
@DrahtBot
Copy link
Contributor

DrahtBot commented Apr 23, 2021

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

@mjdietzx
Copy link
Contributor

  • I really like the implementation of sendrawtransaction in fa1bedb. I can close test: ensure any failing method in MiniWallet leaves no side-effects #20889 (comment) in favor of this, right?
  • Also like the implementation of create_self_transfer and how it's used 👍 in fa085b4
  • I'm confused and still trying to understand what's really going on here fa29382. I see why the original implementation was really confusing (no coins ever mined to ADDRESS_BCRT1_P2WSH_OP_TRUE although the code makes you expect that to happen). But I don't really get why the assertion changes from 250 to 248 assuming it wasn't already failing. And I also don't understand why it fits into this PR. Any explanation here could help me get to an ACK quicker
  • Nice speedup results in fa40eb5. Am I correct that wallet.generate(200) is what is slowing these MiniWallet tests down? And that the approach you use here would be the gold standard for other MiniWallet tests going forward?

@maflcko
Copy link
Member Author

maflcko commented Apr 28, 2021

But I don't really get why the assertion changes from 250 to 248 assuming it wasn't already failing. And I also don't understand why it fits into this PR. Any explanation here could help me get to an ACK quicker

I don't know either why the assertion is there, but the value changes because the block size changes due to the scriptPubKey (size) change.

Am I correct that wallet.generate(200) is what is slowing these MiniWallet tests down? And that the approach you use here would be the gold standard for other MiniWallet tests going forward?

Yes, generate will take time under valgrind, so using the cache when possible will help with a speed-up. Though it is not always possible to use the cache.

Comment on lines +35 to +38
wallet.scan_blocks(start=chain_height - 100 + 1, num=1)
utxo_mature = wallet.get_utxo()
wallet.scan_blocks(start=chain_height - 100 + 2, num=1)
utxo_immature = wallet.get_utxo()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really like this pattern. The method name sync_blocks seems confusing because I wouldn't expect a state change (self._utxos) by this method. It seems this would have to be used very carefully, with knowledge of MiniWallet's internals to avoid bugs. For example, if scan_blocks is called multiple times with any overlapping blocks, then we'll start to get duplicate utxos in self._utxos (maybe this should be a set instead of a list)?

In general I also don't really like how self._utxos is sorted (in send_self_transfer by value), while here it isn't sorted but will have an implicit ordering based on when/how scan_blocks is called, and then based on order of blocks/vouts inside scan_blocks. There's just a lot of different ways it's ordered and we are always relying on that ordering

I'm gonna think this through, don't think this should hold up this PR. But at least I can start the discussion and see what you think / if this can be improved.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. Do you have specific suggestions to improve that pass with all existing tests? Feel free to ping me for review.

@mjdietzx
Copy link
Contributor

crACK fa40eb5

@maflcko maflcko merged commit fb66dbe into bitcoin:master Apr 29, 2021
@maflcko maflcko deleted the 2104-testSpeed branch April 29, 2021 05:15
sidhujag pushed a commit to syscoin/syscoin that referenced this pull request Apr 29, 2021
fa40eb5 test: Speed up mempool_spend_coinbase.py (MarcoFalke)
fa29382 test: Fix test cache issue (MarcoFalke)
fa085b4 test: Create MiniWallet.create_self_transfer (MarcoFalke)
fa1bedb test: Add MiniWallet.sendrawtransaction (MarcoFalke)

Pull request description:

  Locally the test will run 4 seconds faster with `--valgrind` (18s vs 14s)

ACKs for top commit:
  mjdietzx:
    crACK bitcoin@fa40eb5

Tree-SHA512: ecfb60dda5ca5d7e6367bb9c6210390d95ebf6396ce657728901d118b75bb90c98f9351df3b01004d00682234448d6c6a13338d12097f7dced2cf7f1bd84d924
gwillen pushed a commit to ElementsProject/elements that referenced this pull request Jun 1, 2022
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Aug 16, 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.

4 participants