Thread contention around Diagnostics

[pepeiborra]

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:

1. To enqueue the diagnostics update in the debouncer
2. 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