Skip to content
This repository has been archived by the owner on Jan 3, 2019. It is now read-only.

app is too slow to load #31

Open
mackuba opened this issue Aug 19, 2014 · 10 comments
Open

app is too slow to load #31

mackuba opened this issue Aug 19, 2014 · 10 comments

Comments

@mackuba
Copy link
Member

mackuba commented Aug 19, 2014

I have no idea how easy it is to fix it, or if it's the network that is the bottleneck or the CPU, but the fact is, that the app opening experience is far from perfect at the moment.

Compare:

Opening Breadwallet:

  • ~1s to launch
  • ~1s to type PIN
  • ~0s to validate PIN
  • ~2s to sync with the network (but you're free to use the UI at that point)

∑ = 2-3s until it's ready to use.

Opening Hive iOS:

  • ~5s to launch
  • ~1s to type PIN
  • ~10s to do whatever it's doing and move to the main screen

∑ = 16s.

Now, I am currently using the absolutely fastest iPhone currently available on the market. There are people who use iPhone 5, iPhone 4S or iPhone 4, and for them it will take either a bit longer or much longer, depending on how much of that is network and how much is CPU.

I know that Breadwallet validates locally and Hive needs to connect to the server to get a PIN. But: 1) users won't know or won't care, 2) even with a network connection it should take maybe 3s. And the launch shouldn't really take 5s either...

@jenbennings
Copy link
Contributor

This is partly due to UIWebView being throttled by iOS. With the release of iOS 8 Apple is implementing WKWebView, which is much more favourable for hybrid apps (source). People are already reporting significant speed improvements, particularly in regards to javascript (anywhere from 20% to 300%).

The bad news, as you may have guessed, is that this will be an iOS 8+ feature. I believe the Cordova team are working on a way to use WKWebView with a fallback to UIWebView for iOS 7, but it's not ready for primetime yet.

@mackuba
Copy link
Member Author

mackuba commented Aug 20, 2014

Oh, so it won't work automatically after the update to iOS 8, you need to call different SDK code to get the speedup? That sucks.

@dabura667
Copy link

breadwallet is written in objective C and is 100% native for iPhone.

I think the ability to use the same wallet on the web and your phone is a great feature though. (although in actuality... if you wanted to use the hive seed with breadwallet, then you'd get faster access to the same bitcoins... so I could see the dilemma.)

@mackuba
Copy link
Member Author

mackuba commented Aug 20, 2014

breadwallet is written in objective C and is 100% native for iPhone.

I am aware of that, I'm just saying that from a user's perspective it won't matter, they will just compare two competing products, and if one of them starts in 3 seconds and the other in 16, they might be inclined to go with the first one.

@ghost
Copy link

ghost commented Aug 20, 2014

Absolutely right. We have to improve this.

@dabura667
Copy link

breadwallet is written in objective C and is 100% native for iPhone.
I am aware of that, I'm just saying that from a user's perspective it won't matter, they will just compare two competing products, and if one of them starts in 3 seconds and the other in 16, they might be inclined to go with the first one.

I agree. This issue needs to be solved. It's just not surprising, is what I am saying.

Would it be possible to code the local crypto (login section) section only in objective c? or would it be difficult to alter the phonegapped code?

@weilu
Copy link
Member

weilu commented Aug 21, 2014

@jsuder roughly what's the percentage of time spent on "verifying pin" vs "synchronizing wallet"?

@mackuba
Copy link
Member Author

mackuba commented Aug 21, 2014

Almost all of it on "verifying pin", and "synchronizing wallet" is the last 1-2s.

@mackuba
Copy link
Member Author

mackuba commented Aug 21, 2014

So that means it's CPU? What the hell is it doing for 8 seconds?...

@weilu
Copy link
Member

weilu commented Aug 21, 2014

"verifying pin" consists of: one network call to fetch the long token, then AES decrypt the seed, calculate wallet id (sha256 the seed), and init wallet with the seed. A quick profiling suggests that wallet initialization took the longest

Poor man's profiling:

operation ms elapsed since the previous op
start 0
read encrypted credentials from db 1
fetched long token 20
wallet id hashed 12
wallet initialized 221
start syncing 5

Let's zoom into wallet initialization:

operation ms elapsed since the previous op
start 0
master key from seed buffer 92
derived account zero 50
derived external account 46
derived internal account 36

So yeah... computation. We could store the encrypted internal and external accounts and skip all the derivation, which will definitely speed things up.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants