š
Original date posted:2011-06-24
šļø Summary of this message: Jan is seeking advice on how to improve the speed of "getbalance" in Instawallet; a suggestion is made to scan the wallet every time a block comes in.
š Original message:Jan,
On Thu, Jun 23, 2011 at 9:51 PM, <jan at uos.de> wrote:
> Hi there!
>
> Instawallet has enjoyed steady growth and I'm running into a bottleneck
> now with "getbalance <someaccounthere>" taking quite some time to
> complete. My understanding is, that this is because bitcoind runs
> through all relevant transactions each time anew to compute the balance.
> I was hoping the list could give me some pointers/ideas on how I can
> improve this.
>
I think the easiest way to speed this up would be to scan the wallet every
time a block comes in or something else changes in the block chain (or, if
you prefer, some pre-set interval of N minutes). Then go over the entire
wallet and the accumulate balances for all accounts. This could be done in
amortized linear time using a hash_map.
1) This reduces the time the API takes to return the balance for an account
to a predictable, very short time. Just the time to look up the balance in
the hash table (and return 0 on miss). The number crunching happens in the
network thread, not while you're waiting on the API.
2) Less bug-prone than "incremental caching" as you propose, and doesn't
require determining which accounts are influenced by a new block
3) Block chain reorgs are no problem.
JS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110624/3762c70c/attachment.html>;
John Smith [ARCHIVE] /
npub1e4ā¦4jafl
2023-06-07 01:22:41
in reply to nevent1qā¦y8gp
Author Public Key
npub1e4lupyw4vuuhfsmt726ud69555re66pph90kwx0afpt346e9k7zsd4jaflPublished at
2023-06-07 01:22:41Event JSON
{
"id": "3a9ae09ee3c8591f8896d6aafc236883ab549315ecbe96ad6bd2451b8d825cb5",
"pubkey": "cd7fc091d5673974c36bf2b5c6e8b4a5079d6821b95f6719fd48571aeb25b785",
"created_at": 1686100961,
"kind": 1,
"tags": [
[
"e",
"0b3fc1a7bb6f39c49e0e9d490e6ea1c87daab50dea07f3a12027be454b102ce6",
"",
"root"
],
[
"e",
"cd0fc5d80a3cce7fd2f0f8e3baafab786c1bd3f7ff2b767d136c5c81a463116e",
"",
"reply"
],
[
"p",
"05766de3bdda2f0a97052d09e34a9d2cdb31ce60dd4471cbb27acbdde0bc755b"
]
],
"content": "š
Original date posted:2011-06-24\nšļø Summary of this message: Jan is seeking advice on how to improve the speed of \"getbalance\" in Instawallet; a suggestion is made to scan the wallet every time a block comes in.\nš Original message:Jan,\n\nOn Thu, Jun 23, 2011 at 9:51 PM, \u003cjan at uos.de\u003e wrote:\n\n\u003e Hi there!\n\u003e\n\u003e Instawallet has enjoyed steady growth and I'm running into a bottleneck\n\u003e now with \"getbalance \u003csomeaccounthere\u003e\" taking quite some time to\n\u003e complete. My understanding is, that this is because bitcoind runs\n\u003e through all relevant transactions each time anew to compute the balance.\n\u003e I was hoping the list could give me some pointers/ideas on how I can\n\u003e improve this.\n\u003e\n\nI think the easiest way to speed this up would be to scan the wallet every\ntime a block comes in or something else changes in the block chain (or, if\nyou prefer, some pre-set interval of N minutes). Then go over the entire\nwallet and the accumulate balances for all accounts. This could be done in\namortized linear time using a hash_map.\n\n1) This reduces the time the API takes to return the balance for an account\nto a predictable, very short time. Just the time to look up the balance in\nthe hash table (and return 0 on miss). The number crunching happens in the\nnetwork thread, not while you're waiting on the API.\n\n2) Less bug-prone than \"incremental caching\" as you propose, and doesn't\nrequire determining which accounts are influenced by a new block\n\n3) Block chain reorgs are no problem.\n\nJS\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110624/3762c70c/attachment.html\u003e",
"sig": "f1741fed16440e45582bb5774bbd69fd86da3ec9a136dd6f394778dcd0b0f59fdb32a1cb27da988bb03266c5e42e51561c3db045bd82d38c82d6cfc6f4cb0f5d"
}