-
Notifications
You must be signed in to change notification settings - Fork 81
Poor performance of public_address() and public_view_key() #42
Comments
Can't offer much insight in the speed of the specific generation, but can you tell me how are you generating the hundreds/thousands of addresses? A simple for loop? |
Hi. Very basic loop (for now):
The bottleneck are these two lines:
|
Even if the address generation took half the time, doing it hundreds or thousands of times per X will be time consuming without parallelism. This could be a good next step: import concurrent.futures
from monero import seed
from time import time
# Times to loop
loop_count = 100
def generate_seed():
s = seed.Seed()
s_address = s.public_address()
print(f"Generated new address: {s_address}")
return s_address
def main():
with concurrent.futures.ProcessPoolExecutor() as executor:
futures = []
for i in range(loop_count):
future = executor.submit(generate_seed)
futures.append(future)
if __name__ == "__main__":
t_start = time()
main()
t_end = time()
t_total = t_end - t_start
print(f"\n\n[+] {t_total} seconds elapsed generating {loop_count} addresses.") $ python -V
Python 3.6.0 |
Output of script:
|
Thanks. I will look into it. Nevertheless, it still would be intresting to know why it is so slow. If not now, then then in the long term, it would be valuable. |
It's slow because neither our ed25519 implementation is optimal, nor handling of its outputs is. It's pure Python and it was designed to serve the most common use cases in the first row, namely having a working wallet with full features, not optimized for horizontal scaling. For example, the keys are internally kept as string hex representations because it's human-readable. However, for computations it would be much faster to keep the The best solution would be to make some optimizations in Python code but also switch over to a low-level implementation of ed25519 arithmetic, like libsodium or orlp's. However, that requires creating Python/C bindings and dealing with all new set of problems typical to low-level solutions (building on different platforms, falling back to pure Python when lib is unavaliable, etc.) Any help from a person experienced in this kind of work would be very welcome. |
I looked into the code. I see the problem is that But, I also found that
where |
Could you create a PR for that value caching? Just please prepend underscore to the attribute names ( PS: I'm pretty sure that recursion in |
@emesik Regarding |
Thanks! |
No problem. |
Little updated. Ended up using the address generator in As a side note. The issue originated from development of short |
I managed to go from seed->public address in This is offtopic for monero-python however. |
With 9aee656 I have changed the ed25519 implementation to one that cut the test suite running time by two orders of magnitude. Integrating low-level C/C++ code from monero or libsodium could potentially cut the times further, however we still stay in pure Python world, so I stopped looking for other solutions ATM. |
I'm using your project (good work by the way!) to generate hundreds/thousands of addresses and get their public address and private keys. But their generation is, unexpectedly, very slow. Some basic tests in python using timeit on Intel Core i7-3820 @ 3.8GHz:
Any reason for this poor performance and any way/fix to make it faster? Generation of thousands addresses and keys on regular basis with that speed (basically one every 1 to 2 seconds) is slow.
The text was updated successfully, but these errors were encountered: