# Multithreading and coverage counters: disable coverage by default?
**URL:** https://yosyshq.discourse.group/t/multithreading-and-coverage-counters-disable-coverage-by-default/105
**Category:** Developers
**Created:** [November 26, 2025, 12:28am UTC](https://yosyshq.discourse.group/t/multithreading-and-coverage-counters-disable-coverage-by-default/105 "2025-11-26T00:28:42Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@rocallahan](https://yosyshq.discourse.group/u/rocallahan)
#### Post date: [November 26, 2025, 12:28am UTC](https://yosyshq.discourse.group/t/multithreading-and-coverage-counters-disable-coverage-by-default/105/1 "2025-11-26T00:28:42Z")
Coverage counters currently aren’t thread-safe but that’s [easily fixed](https://github.com/YosysHQ/yosys/pull/5515).
However, they significantly hurt performance when multithreading with large numbers of cores. For my parallel `opt_merge` pass doing multithreaded read-only access to RTLIL, on 20 cores I get 7.5x speedup over 1 core with (threadsafe) coverage enabled, 14.1x speedup with coverage disabled.
(With the current non-threadsafe data-racy counters, the speedup is even less than with the atomic counters, only 7x, which is a bit weird but suggests that the main cost is cache-line ownership ping-ponging between cores. The numbers might vary a lot depending on the hardware.)
Currently coverage is enabled by default on Linux and FreeBSD (and doesn’t work on other platforms). Personally I haven’t ever used its coverage data. Threading is enabled by default on most targets, and when we start using it for core passes like `opt_merge` most users should see significant benefits from turning off coverage. Should we disable coverage by default?
---
### Author:  [@rocallahan](https://yosyshq.discourse.group/u/rocallahan)
#### Post date: [November 26, 2025, 12:32am UTC](https://yosyshq.discourse.group/t/multithreading-and-coverage-counters-disable-coverage-by-default/105/2 "2025-11-26T00:32:16Z")
One alternative would be to reimplement the counters using thread-local data, but I’m not sure if the current approach using ELF sections would work and it would probably be more complicated.
---
### Author:  [@widlarizer](https://yosyshq.discourse.group/u/widlarizer)
#### Post date: [November 26, 2025, 1:31pm UTC](https://yosyshq.discourse.group/t/multithreading-and-coverage-counters-disable-coverage-by-default/105/3 "2025-11-26T13:31:51Z")
Yikes, I never noticed we have this cooked coverage mechanism on by default. On current main there’s no performance change when I disabled it at least. I’m pretty sure it’s useless and unused. It has nothing to do with gcov or things like `$cover` or the linecoverage command, and I just checked that there are no actual uses of it on all of github either. If it’s convenient for you to remove it outright, go ahead