You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, SigningState is being held behind a RwLock, which can lead to contention when there are multiple operations going on (i.e. claim_oidc, reveal, signature_share). This can actually slow down another person's new_account request if there are multiple ones going on, where each are trying to acquire the write lock.
We need concurrent key insertions is the issue here, since we have multiple entry points for modifying the keys in each of the HashMaps. But before making this optimization, we should wait until #233 is complete to compare easily.
one simple speed up we can do is to internalize the RwLock, such that each HashMap has its own RwLock:
Currently,
SigningState
is being held behind aRwLock
, which can lead to contention when there are multiple operations going on (i.e.claim_oidc
,reveal
,signature_share
). This can actually slow down another person'snew_account
request if there are multiple ones going on, where each are trying to acquire the write lock.Our current
SigningState
looks like:https://github.com/near/mpc-recovery/blob/29b64781969f944a4aa273d181d85689e156dc52/mpc-recovery/src/sign_node/aggregate_signer.rs#L21-L24
We need concurrent key insertions is the issue here, since we have multiple entry points for modifying the keys in each of the
HashMap
s. But before making this optimization, we should wait until #233 is complete to compare easily.one simple speed up we can do is to internalize the
RwLock
, such that eachHashMap
has its ownRwLock
:@volovyks @itegulov @DavidM-D lmk what you guys think
The text was updated successfully, but these errors were encountered: