/cc @theoy @MattGertz

I guess it is the easiest way to know for sure.

LGTM

The performance numbers so far look good - no noticeable regression in performance at all. We'll have more soon.

👍

Batch compiler performance tests reveal no regression. Running IDE and typing performance tests now...

IDE tests look good too.
From a performance point of view, this change has negligible impact.

Do you have tests that test a large set of reference assemblies, such as Store, Phone, UAP, or portable?

Also some 30MB assembly produced by C++/CLI would be good to include in such testing

@davkean We have large sets, but all our perf tests are desktop solutions. Why do you think other target frameworks would be significant?

@tmat why? The perf concern is that we now have to check all assemblies, so a C++/CLI assembly with hand-written extension methods would be treated just the same as a VB or C# one.

@pharring Because, unlike desktop which typically only references small amounts of assemblies from the framework (only the ones the templates or user has chosen), the rest of the project types automatically reference 60 - 100 assemblies by default.

@pharring Should clarify, what I mean is that it doesn't matter if it's desktop or something else, as long as something with a significant amount of referenced assemblies is represented.

@pharring
If an assembly reference doesn't have an extension attribute on its AssemblyDef wouldn't we now need to check all its methods for the attribute to determine that there are no public extension methods declared in it?

@tmat Yes, exactly. That's why this is a performance concern for all compilations. It doesn't matter whether the referenced assembly is written in C#, C++/CLI or Martian.

@davkean I understand. We don't have such automated tests today. We can do manual testing for it. Do you think that building the portable pieces of Roslyn itself would be a good enough test?

@tmat Not exactly. We now have to check all types in the assembly. We still require the containing type to be attributed.

@pharring Yes, assuming that you are opt'ing into the default behavior of portable (<ImplicitlyExpandTargetFramework>true</ImplicitlyExpandTargetFramework>), and not building against packages representing the framework.

Update: Editor ate my XML tags.

@gafter @Pharing OK, so we check all types. The reason why I'm mentioning C++ is that managed C++ may generate enormous assemblies with a lot of types, unlike C# and VB.

@AlekseyTs FYI