Revise LockSelector's locking strategy
Closed this issue · 1 comments
Currently, LockSelector is used excessively inside the DefaultCombat code base. What this effectively does is acquire a lock for the PrioritySelector it decorates.
From a theoretical perspective, this ensures the state of the game is guaranteed inside every PrioritySelector, regardless of whether or not a lock was acquired before or not. However, since the PrioritySelector will have no knowledge of already acquired locks, this could potentially lead to nested locks, which will nuke performance.
There are various possible solutions to this problem, the most obvious being not using a LockSelector anywhere other than the "root" PrioritySelector for the combat routine. Another option would be a AcquireLockSafe method or similar, which would ensure a frame lock would only be obtained if none was previously held.
Some routines already have made these changes by the way of pull requests, and it may be a good idea to revise this for all routines, in order to drastically increase performance of the routine.
Yes i have gone from 10-15 fps to 50-60 FPS just by changing Lockselector to Priorityselector in the actual routine and DefaultCombat.cs.