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 the heap size is changing at each insert, remove, and decrease operation. When it reaches _maxSortedUsers, it is divided by 2. The informal goal is to distribute high liquidity evenly on the branches of the heap, in order to maximize the total liquidity that is in the heap.
One other idea would be distribute the incoming liquidity "randomly" on the last nodes before _maxSortedUsers. This means that the size of the heap would only change up to _maxSortedUsers and then stay the same, potentially saving one SSTORE for each operation. Another potential benefit would be that the introduced randomness would mostly prevent worst case scenarios for the incoming liquidity.
Note that there is no real need for the randomness here to be truly random, and we could use a pseudo-random function instead.
Found by @MathisGD.
Currently the heap size is changing at each
insert,remove, anddecreaseoperation. When it reaches_maxSortedUsers, it is divided by 2. The informal goal is to distribute high liquidity evenly on the branches of the heap, in order to maximize the total liquidity that is in the heap.One other idea would be distribute the incoming liquidity "randomly" on the last nodes before
_maxSortedUsers. This means that the size of the heap would only change up to_maxSortedUsersand then stay the same, potentially saving oneSSTOREfor each operation. Another potential benefit would be that the introduced randomness would mostly prevent worst case scenarios for the incoming liquidity.Note that there is no real need for the randomness here to be truly random, and we could use a pseudo-random function instead.