Spikes in CPU usage when resolving references to methods implementing System.IDisposable

[SirIntruder]

Finding references to a method that implement System.IDisposable in any non-trivially sized project takes a long time and causes a big spike in CPU usage. I replicated this behaviour in VS2019, VS2017 and VSCode with omnisharp. It's impossible to avoid this issue if you want to use Code Lens.

After making a cpu profile, it seems that core issue is here:

roslyn/src/Workspaces/Core/Portable/FindSymbols/FindReferences/DependentProjectsFinder.cs

Lines 442 to 464 in d570d6c

	// WORKAROUND:
	// perf check metadata reference using newly created empty compilation with only metadata references.
	//
	// TODO(cyrusn): Why don't we call project.TryGetCompilation first?
	// wouldn't we want to use that compilation if it's available?
	var compilation = project.LanguageServices.CompilationFactory.CreateCompilation(
	project.AssemblyName, project.CompilationOptions);
	compilation = compilation.AddReferences(project.MetadataReferences);
	foreach (var reference in project.MetadataReferences)
	{
	cancellationToken.ThrowIfCancellationRequested();
	if (compilation.GetAssemblyOrModuleSymbol(reference) is IAssemblySymbol symbol)
	{
	var result = predicate(symbol);
	if (result != null)
	{
	return result;
	}
	}
	}

Namely, to find references to MyClass.Dispose(), Roslyn first tries to find all classes that implement System.IDisposable, with first step being filtering all projects in solution to those which have access to assembly containing System.IDisposable. Checking whether a project has access to the said assembly involves creating a whole new compilation object, and this is what seems to be taking most of the cpu cycles.

I assume what @CyrusNajmabadi remarked in the TODO would resolve/help with this issue?

[jmarolf]

In past we had optimizations here to not do full FAR on IDisposeable and object members (like ToString) since there are likely going to be tens of thousands of those in large project and finding every location of ToString is not worth the electricity. We should add a filter in front of our Call to SymbolFind.FindRefernces to exclude these types or do a more targeted type search.

[CyrusNajmabadi]

Can a repro/trace be supplied here?

[ghost]

Closing this issue as we've seen no reply to the request for more information. If you are able to get the requested information, please add it to the issue and we will retriage it.