1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <witchspace81@gmail.com>) id 1QZyyr-0002Hy-09
for bitcoin-development@lists.sourceforge.net;
Fri, 24 Jun 2011 05:31:01 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.218.47 as permitted sender)
client-ip=209.85.218.47; envelope-from=witchspace81@gmail.com;
helo=mail-yi0-f47.google.com;
Received: from mail-yi0-f47.google.com ([209.85.218.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1QZyyp-0006rg-Om
for bitcoin-development@lists.sourceforge.net;
Fri, 24 Jun 2011 05:31:00 +0000
Received: by yib18 with SMTP id 18so1333312yib.34
for <bitcoin-development@lists.sourceforge.net>;
Thu, 23 Jun 2011 22:30:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.145.12 with SMTP id s12mr3114356ybd.20.1308893454256; Thu,
23 Jun 2011 22:30:54 -0700 (PDT)
Received: by 10.151.50.21 with HTTP; Thu, 23 Jun 2011 22:30:54 -0700 (PDT)
In-Reply-To: <20110623215143.GA3351@dax.lan.local>
References: <20110623215143.GA3351@dax.lan.local>
Date: Fri, 24 Jun 2011 05:30:54 +0000
Message-ID: <BANLkTi=eSgC0T_mKn660dZv1h+g-Z9TU+g@mail.gmail.com>
From: John Smith <witchspace81@gmail.com>
To: jan@uos.de
Content-Type: multipart/alternative; boundary=000e0cd47ea463c9e004a66e8137
X-Spam-Score: 1.6 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is freemail (witchspace81[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
2.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (witchspace81[at]gmail.com)
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.0 RFC_ABUSE_POST Both abuse and postmaster missing on sender domain
0.0 T_TO_NO_BRKTS_FREEMAIL T_TO_NO_BRKTS_FREEMAIL
X-Headers-End: 1QZyyp-0006rg-Om
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Speeding up "getbalance <account>" calls
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 24 Jun 2011 05:31:01 -0000
--000e0cd47ea463c9e004a66e8137
Content-Type: text/plain; charset=ISO-8859-1
Jan,
On Thu, Jun 23, 2011 at 9:51 PM, <jan@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
--000e0cd47ea463c9e004a66e8137
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Jan,<br><br><div class=3D"gmail_quote">On Thu, Jun 23, 2011 at 9:51 PM, <s=
pan dir=3D"ltr"><<a href=3D"mailto:jan@uos.de">jan@uos.de</a>></span>=
wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex;">
Hi there!<br>
<br>
Instawallet has enjoyed steady growth and I'm running into a bottleneck=
<br>
now with "getbalance <someaccounthere>" taking quite some t=
ime to<br>
complete. My understanding is, that this is because bitcoind runs<br>
through all relevant transactions each time anew to compute the balance.<br=
>
I was hoping the list could give me some pointers/ideas on how I can<br>
improve this.<br></blockquote><div><br>I think the easiest way to speed thi=
s up would be to scan the wallet=20
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=20
the entire wallet and the accumulate balances for all accounts. This could
be done in amortized linear time using a hash_map.<br>
<br>
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.<br>
<br>
2) Less bug-prone than "incremental caching" as you propose, and=
=20
doesn't require determining which accounts are influenced by a new bloc=
k<br><br>3) Block chain reorgs are no problem.<br>
<br>JS<br><br></div></div>
--000e0cd47ea463c9e004a66e8137--
|
