Cache type refs during import

[gluck]

trafficstars

• importing many types/methods would result in millions of duplicate TypeRef objects, this basic caching saves lots of memory in that use case.
• one issue with it has to do with Cecil not filling up GenericParameters for all types (hence the workaround). Was seen during Dapper or Bcl UTs.

I guess this change can be debated, but as it bring a large perf impact for ILRepack (~20%), I kind'o need it :smile: Other ways to tackle it would be:

• to add an option for the metadataimporter to cache (or not)
• make the metadataimporter public & overrideable, so that one (ILRepack) could add a caching layer on top of it

If those sound more appropriate for Cecil, I can modify this PR accordingly (though IMO, all import use cases would benefit from this cache).

MethodRef could/should be cached similarly, but the impact is lesser than TypeRefs.

[jbevain]

It's now easy for you to override the MetadataImporter with your own. See ReaderParameters.MetadataImporterProvider

[gluck]

Oh missed that, thanks. Though right now (correct me if I'm wrong), if I want to add this TypeRef cache on top of the regular MetadataImporter, I need to re-write (copy/paste) it entirely, and I'll probably miss some internal-only bits (e.g. the last merged PR from me requires internal visibility).

[jbevain]

I'm pretty sure you can extend MetadataImporter and override ImportReference to call base.ImportReference only if not cached.

[gluck]

That would work if the MetadataImporter called ImportReferences in its various Import methods, but it doesn't, it calls ImportType instead (private).

[gluck]

(I can make a PR to change only that, and will be able to manage the caching on my side then)

[jbevain]

Right. Let me think about it some more and I'll get back to you.

[SimonCropp]

@jbevain is this still a viable change?