-
Notifications
You must be signed in to change notification settings - Fork 38.7k
[Wallet] Remove CWalletDB* parameter from CWallet::AddToWallet #8152
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
[Wallet] Remove CWalletDB* parameter from CWallet::AddToWallet #8152
Conversation
src/wallet/wallet.cpp
Outdated
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.
just curious: what is the reason to not keep a instance variable (within CWallet) that holds walletdb object? What are the benefits of constantly opening/instantiating the CWalletDB?
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.
The scope is used to manage the lifetime of the (database) transaction.
So having a single CWalletDB object would change semantics significantly. Some people have had this idea before but it was always rejected.
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.
@jonasschnelli I will eventually get to that point, but it's going to take a significant amount of work to get there.
|
I think the persistent CWalletDb object here is just there to prevent a flush to disk in between every added transaction, for performance reasons. Based on earlier pull requests by @pstratem around this, I think he intends to re-introduce a single CWalletDb* inside CWallet rather than reopening one all the time, after cleaning things up. Perhaps that will need to be done in the same PR, though? |
I think provided it is done before a release, there is no issue. |
|
I think there is no advantage merging this small refactoring early. Might as well just add the second commit to address @jonasschnelli s and @sipa s feedback. |
|
Regardless of the persistent CWalletDB * I think this PR has value (refactoring). But I guess we should not change the |
|
A refactoring shouldn't result in behavioral changes. I'd rather stick with ugly code somewhat longer than introduce a temporary (but serious) performance regression. |
At least then you'll have users reminding you 😆 |
|
I've split up AddToWallet into AddToWallet and LoadToWallet around the fFromLoadWallet flag. This addresses the performance @jonasschnelli noticed and improves the API. |
b456663 to
175dcdc
Compare
|
I swapped the order of the commits such that there's no performance issue at any point. 22fa63e74150139c7c71108ee46ed87d31a4a2f3c171d16c34530f76ecc79f82 |
175dcdc to
2a20b89
Compare
|
import hashlib;hashlib.sha256("there is still a performance issue").hexdigest() there isn't actually |
2a20b89 to
072571c
Compare
072571c to
44d5267
Compare
src/wallet/wallet.cpp
Outdated
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.
IMO the non-file-backend state is only used in UnitTests, right? We should also consider dropping it completely (in a later PR).
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.
I'll be able to easily remove it once more of the logic is encapsulated.
|
utACK 44d5267bfcd8abae5f0ae2a0f4052fc5a88acd2e |
|
utACK 44d5267 |
44d5267 to
6246add
Compare
|
tACK 6246add89a46523526a57b66bb87daf9413c69d7 |
|
Seems 6246add is just a plain rebase of 44d5267 re-utACK 6246add |
|
@MarcoFalke indeed it is |
|
Looks good now! |
|
@jonasschnelli I'd rather not squash, each commit is logically independent. |
src/wallet/wallet.cpp
Outdated
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.
This can go
Edit: Note that the parameters under which walletdb are opened change here - it used to be specifically overriding the flush to false, but after this change, the walletdb will be opened inside AddToWallet with default parameters.
What is the impact of this?
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.
Indeed this can go. I'll run a benchmark of master and this pr doing a rescan with a wallet that has an enormous number of transactions and keys.
|
utACK c04225e7fdb9651ae2f97ed0e3f9601205ea858b |
This removes the fFromLoadWallet flag in AddToWallet. These were already effectively two methods.
3c6a33e to
5723bb4
Compare
|
@laanwj I was having trouble getting consistent benchmark results from -rescan (+-30 seconds on runs taking 160-200 seconds). So I just added an fFlushOnClose parameter so it's now clearly doing the same thing as before the change. |
|
reutACK 5723bb4 |
|
Indeed I generally agree, but I was already squashing adding the Whenever possible I strongly prefer that each commit produces a complete On Jul 31, 2016 3:56 AM, "MarcoFalke" [email protected] wrote:
|
|
With rebase I meant changing the commit which the pull is based on, reACK 5723bb4 |
This is the last method to pass a CWalletDB