Skip to content
This repository has been archived by the owner on Nov 15, 2021. It is now read-only.

Addressing performance problems with OpenCover

Shaun Wilde edited this page Aug 12, 2021 · 1 revision

Introducing a profiler like OpenCover into your code is going to have some impact on performance and possibly an impact on the results. Depending on what the code does and the size of your codebase this can vary. For unit tests running in a CI environment, this may not be an issue. If it is a problem then you may want to review the following hints and tips.

  1. Use DebugView to see any runtime errors emitted from the profiler, increase logging verbosity to full using the -log:All switch
  2. If you find that certain assemblies are not being covered then if you are sure it isn't the filters then it may be that the assembly is too big and takes longer than normal to process, try extending the timeout using the following switch -communicationtimeout:600000
  3. If you only care about coverage and not the number of hits per sequence point you can improve performance a bit more using the following argument -threshold:1
  4. OpenCover has to inject a complex piece of IL to bypass any security issues that are seen when profiling Silverlight (yes I know it is not supported) or assemblies that are using the AllowPartiallyTrustedCallersAttribute (no longer supported in .net core). To switch to a simpler injection method the try the -oldschool argument.

If you don't care try the above out individually and just want to move on, then just throw in the following

-log:All -communicationtimeout:600000 -oldstyle -threshold:1