add ECPoint cache #2616
add ECPoint cache #2616
Conversation
|
|
src/neo/Cryptography/ECC/ECPoint.cs
Outdated
| p = DecompressPoint(yTilde, X1, curve); | ||
| p._compressedPoint = encoded.ToArray(); | ||
| byte[] compressedPoint = encoded.ToArray(); | ||
| if (pointCache.TryGet(compressedPoint, out ECPoint inventory)) |
There was a problem hiding this comment.
The cache is not curve dependant
|
Ping |
|
Is this more effective for offline synchronization? |
Yes, without this PR it would need about 25 seconds to sync 10000 blocks offline in "--noverify" mode. |
|
Then I suggest adding this cache to the offline synchronization module. |
But according to #2616 (comment) this PR can also enhance TPS... |
|
I'd just comment on our experience with this. Way back when in #1321 days we've added similar cache specifically for block processing, the difference there was huge, 30% faster block imports were really important for us. Then at some point in time we've started optimizing our node and discovered that key decoding is an important part of the process there also, so we've generalized this cache and made it system-wide (applicable for any key decoding), that had improved our TPS metrics somewhat (as a part of nspcc-dev/neo-go#1396, ~5% improvement from this particular change). On C# side this PR easily (there is not a lot of code that it adds) improves TPS metrics by 14%. Sure, this particular neo-bench test is somewhat complimentary for this kind of change because it doesn't use many addresses and thus always has 100% cache hit for all keys. At the same time on a real network we're still very likely to see the same keys being used for transactions in subsequent blocks, so it's important and it will help there (I'd only suggest making the cache a bit larger, keys are rather small, so having a 1000 of them in memory is not a big problem). |
No ImportBlocks any more. |
|
merge? |
|
@shargon @erikzhang Merge? |
|
The right one is with this PR, 2x speed on offline sync. |
Close #2614