Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add some test suite benchmarking for group encryption/decryption performance.
Quick takeaway: on my desktop system:
Tests from running qemu arm64 emulation, still on my desktop:
And on a native arm64 Raspberry Pi:
(I'm more than a bit surprised that emulated arm64 performs that well--faster on the encryption and not that much slower on the decryption).
I don't think that's slow enough to worry about optimizing, at least for now (remember, these are 1000-member groups; a 100-member group is going to be 10x as fast), but if we did need more performance we could precompute the
aM
(group-priv-key times member-pubkey) value for all of the group members to get times of (amd64/arm64-qemu/arm64):i.e. most of the encryption time is spent doing crypto operations to compute each member's encryption key, not the encryption itself. (This is also why decryption is so much faster in the first place: there's only one crypto multiplication calculation for each member, of
mA
, rather than 1000 calculations ofaM
for each of 1000 differentM
s).The only problem with this caching is that you still have to do all the
aM
computations somewhere, so you still have to eat that extra time at some point, and then store them. So I'll put it down as a stretch goal for libsession-util to do such caching, but not something we need to launch new groups.