SomaticFanatic
commented
4 years ago Not sure if this is related but my OSX laptop’s SSD took over two days to sync from scratch (using 0.16) which seemed unreasonably long to me
Open WooKeyWallet opened 4 years ago
SomaticFanatic
commented
4 years ago Not sure if this is related but my OSX laptop’s SSD took over two days to sync from scratch (using 0.16) which seemed unreasonably long to me
selsta
commented
4 years ago @SomaticFanatic Did you self compile v0.16 from master branch? I tested v0.16 and was able to sync up in 2:40 on a 30€/month VPS.
SomaticFanatic
commented
4 years ago @selsta was your VPS OSX? That’s more the issue I’m focused on. My Linux box synced fine
selsta
commented
4 years ago Which is the exact commit you compiled?
I also own a 2014 MacBook and can test later.
SomaticFanatic
commented
4 years ago Cloned master and compiled. Last master commit was 15 days ago.
https://github.com/monero-project/monero/commit/70609d76814bfd1dcabb813d45bbd367597aaa95
selsta
commented
4 years ago master does not contain the updated fast sync checkpoints yet. Try again with release-v0.16 branch or v0.16.0.0 tag.
moneromooo-monero
commented
4 years ago Those don't impact wallet sync speed though.
WooKeyWallet
commented
4 years ago Those don't impact wallet sync speed though.
I have found that time-consuming method：
bool crypto_ops::derive_subaddress_public_key(const public_key &out_key, const key_derivation &derivation, std::size_t output_index, public_key &derived_key) {
ec_scalar scalar;
ge_p3 point1;
ge_p3 point2;
ge_cached point3;
ge_p1p1 point4;
ge_p2 point5;
if (ge_frombytes_vartime(&point1, &out_key) != 0) {
return false;
}
derivation_to_scalar(derivation, output_index, scalar);
ge_scalarmult_base(&point2, &scalar);
ge_p3_to_cached(&point3, &point2);
ge_sub(&point4, &point1, &point3);
ge_p1p1_to_p2(&point5, &point4);
ge_tobytes(&derived_key, &point5);
return true;
}
We found that in release-0.15 version, iOS performance is obviously not as good as Android. We compared Monroe wallets including self-developed and cakewallet.
I tracked the running status of the app, the screenshot is as follows:
When 100% of the CPU occurs, I check the threads and find that there are two Monero wallet threads that are very time-consuming and occupy CPU when parsing the block. The call stack is displayed as follows: