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
These shared locks introduce contention and resulting in decreasing performance as the core count increases.
1. Debouncer
The async debouncer that we use in ghcide to deduplicate diagnostics is backed by a single lock containing a Hashmap indexed by rule key used to store all the pending actions. We then grab this lock for every rule execution, for rules with diagnostics. In total, a rule execution grabs the lock twice:
To enqueue the diagnostics update in the debouncer
When the update fires, to clean up
We then hold the lock for as long as it takes to update the map and cancel the previous async, if any. There is a bit of room for improvement here, by combining HashMap accesses as well as executing the cancel outside the lock.
Moreover, I have added an option to install a different Debouncer, e.g. the noopDebouncer, if desired.
2. Diagnostics lock
We store all the published diagnostics in a HashMap indexed by NFP behind a single lock. We then grab this lock once for every rule execution, for rules with diagnostics, and hold it for the whole publish loop. We can do better by executing the publish loop out of the lock
The text was updated successfully, but these errors were encountered:
pepeiborra
changed the title
Debouncer & Diagnostics: minor improvements
Thread contention around Diagnostics
Mar 10, 2021
These shared locks introduce contention and resulting in decreasing performance as the core count increases.
1. Debouncer
The async debouncer that we use in ghcide to deduplicate diagnostics is backed by a single lock containing a Hashmap indexed by rule key used to store all the pending actions. We then grab this lock for every rule execution, for rules with diagnostics. In total, a rule execution grabs the lock twice:
We then hold the lock for as long as it takes to update the map and cancel the previous async, if any. There is a bit of room for improvement here, by combining HashMap accesses as well as executing the cancel outside the lock.
Moreover, I have added an option to install a different Debouncer, e.g. the
noopDebouncer
, if desired.2. Diagnostics lock
We store all the published diagnostics in a HashMap indexed by NFP behind a single lock. We then grab this lock once for every rule execution, for rules with diagnostics, and hold it for the whole publish loop. We can do better by executing the publish loop out of the lock
The text was updated successfully, but these errors were encountered: