GC pressure in CompositionConfiguration even when loading from cache about vs-mef HOT 6 CLOSED

You're right. The cache is loaded using catalogManager.LoadAsync() and then this CompositionConfiguration.Create() API is called. I guess I need to re-work my caching mechanism to avoid this when loading from cache.

from vs-mef.

FindLoops isn't called when loading a graph from the cache. It's only called from CompositionConfiguration.Create(catalog). So you might have cached the catalog, but you're creating the graph at runtime, and that's when loops must be detected.
If you actually cache the graph itself, it wouldn't execute this code.

Regarding the GC pressure, I see exactly one use of the Where extension method. We might be able to replace this in order to avoid some allocations. But if you meant to be caching the graph and can fix that, the cost of creating the graph will entirely go away.

from vs-mef.

Use the CachedComposition class here to cache the graph itself.

from vs-mef.

This will certainly improve startup performance in our app. Thanks for that link!

Still, I think you should get rid of those Where and Select calls. Together they account for 200 MB allocations in our huge app.

from vs-mef.

Together they account for 200 MB allocations in our huge app.

I doubt that. I think you're misattributing all the code that runs in the delegates to the use of Where and Select directly. If we removed use of those extension methods we'd still need to run the code in the delegates, so almost all those allocations would still occur.

from vs-mef.

Possibly. But a million enumerator allocations would certainly be of importance. We have an enormous amount of exports and imports.

from vs-mef.