Memory pool mutex is locked/unlocked for each wallet transaction in loop resulting in unnecessary overhead. This patch makes it one time lock/unlock (even if there are no wallet transactions).
wallet: Improve ReacceptWalletTransactions performance #11865
pull promag wants to merge 1 commits into bitcoin:master from promag:2017-12-improve-reaccept-wallet-transactions changing 1 files +2 −3-
promag commented at 3:40 PM on December 11, 2017: member
-
wallet: Improve ReacceptWalletTransactions performance 6de7bdd801
-
TheBlueMatt commented at 3:44 PM on December 11, 2017: member
Did you find this while testing? I'm skeptical there is any real overhead. On the other hand, I find it astoundingly strange that wallet has any concept of mempool.cs - I'd strongly prefer we simply remove that LOCK (assume there isnt much overhead, which I'd bet is true given we're holding cs_main the whole time).
-
promag commented at 4:17 PM on December 11, 2017: member
Why do you think there's no overhead?
-
TheBlueMatt commented at 4:20 PM on December 11, 2017: member
Overhead of taking a lock that has no contention should be realtively minimal, especially compared to things like signature checking, and wallet having a concept of what mempool lock there is (especially when other calls to ATMP do not) is nonsense to me.
-
promag commented at 4:25 PM on December 11, 2017: member
Yes comparing to those things (https://stackoverflow.com/questions/41531836/mutex-lock-speed-difference-inside-and-outisde-the-foor-loop).
-
promag commented at 4:26 PM on December 11, 2017: member
Agree that this lock is at least out of place. I'll open a new PR removing the lock.
- promag closed this on Dec 11, 2017
- fanquake added the label Wallet on Dec 11, 2017
- DrahtBot locked this on Sep 8, 2021
Contributors
Labels