search

danielmcclure / bitcoinj

Automatically exported from code.google.com/p/bitcoinj
Apache License 2.0
0 stars 1 forks source link

WalletProtobufSerializer.readWallet() performance regression #592

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Since HD wallets, loading an almost empty wallet takes 1.5-2 seconds on a Nexus 
7 (2013). I have investigated into this.

Most of the time is spent in DeterministicKeyChain.fromProtobuf(). In my test 
wallet there are 272 keys, each key takes ~7ms to iterate each. A special case 
is the first key of type DETERMINISTIC_KEY, because it takes 250ms (due to 
actually creating the DeterministicKeyChain object).

I wonder how much of that stuff we can do lazily. Bitcoin Wallet is currently 
based on the assumption that loading the wallet is quick enough to do it when 
constructing the application while most wallet accessors are executed on a 
worker thread.

Original issue reported on code.google.com by andreas....@gmail.com on 18 Nov 2014 at 12:09

GoogleCodeExporter commented 9 years ago 
Is that with ART?

7msec is very slow given all it's doing is moving data from one data structure 
to another. Could you provide the complete profiles? Which part of loading a 
key is slowing us down? Perhaps hash table inserts?

Also, 250msec is again way too slow for just loading stuff into RAM from disk, 
which is all this code is doing really. I know Dalvik is slow but those numbers 
are pretty nuts. Doing more profiling would be really useful.

Original comment by mh.in.en...@gmail.com on 18 Nov 2014 at 12:51

GoogleCodeExporter commented 9 years ago 
It's Dalvik.

Original comment by andreas....@gmail.com on 18 Nov 2014 at 1:19

GoogleCodeExporter commented 9 years ago 
Just noticed I got the year of my Nexus wrong. I've got the first Nexus 7 from 
2012.

Original comment by andreas....@gmail.com on 18 Nov 2014 at 2:39

GoogleCodeExporter commented 9 years ago 
Mike, the patch you sent me reduced the wallet load time from 1.5-2s to 1-1.2s. 
So that's not bad for starters.

Original comment by andreas....@gmail.com on 18 Nov 2014 at 3:09

GoogleCodeExporter commented 9 years ago 
The second patch reduced it further down to 300-400ms. Nice!

Original comment by andreas....@gmail.com on 18 Nov 2014 at 7:37

GoogleCodeExporter commented 9 years ago 
Any news on this issue?

Original comment by diogogso...@gmail.com on 3 Jan 2015 at 2:41

GoogleCodeExporter commented 9 years ago 
Nothing after the latest speedup. Next step is to get the code released.

Original comment by andreas....@gmail.com on 3 Jan 2015 at 2:52