Performance compared to MEF 2

[BalintPogatsa]

There is a comparison library for several IoC implementations. Comparing VS MEF to MEF 2 shows that VS MEF is only better in startup performance, but significantly slower in other benchmarks:
https://github.com/danielpalme/IocPerformance

Compared versions (this is the nuget package version - the screenshot displays the assembly version):

• VS MEF: 16.1.8
• MEF2: 1.2.0

Do you think it is still justifiable in some cases to use VS MEF over MEF 2? Or could be there a conceptual problem why these benchmark values are worse? Do you maybe have other benchmarks that shows a different picture?

[weltkante]

It doesn't look like you linked to a repository containing a VS MEF benchmark, I only found danielpalme/IocPerformance#120. Maybe you can share your implementation instead of just showing some numbers?

[BalintPogatsa]

I will when I find the time. Do you also have some performance comparison that I could check?

[weltkante]

No I don't have measurements, but I'm using VS MEF in a few projects and could check if there's anything obviously wrong in the benchmark. It sounds surprising that VS MEF should be that much slower considering that the whole dependency graph is precalculated.

[BalintPogatsa]

VS MEF was merged to the main repository of this benchmark:
https://github.com/danielpalme/IocPerformance

If you want to take a look at the comparison using the AppHost package (running the console app will give the result only for Mef 2 and VS Mef):
https://github.com/BalintPogatsa/IocPerformance

[znakeeye]

I just ported a super large MEF application to Vs-Mef (targeting .NET 4.5.2). My conclusions so far:

• Startup is slightly faster if and only if you read the graph from a serialized cache.
• Performance overall was not affected.

I suppose the async APIs can be used to further improve performance. Still, I would expect a significant performance gain compared to the old CompositionContainer.

[znakeeye]

Could the performance discrepancies have anything to do with jitting? I.e. MEF2 is already jitted when the benchmark is performed, whereas vs-mef is not.

[AArnott]

That might explain a startup cost, but not a throughput perf difference.
The throughput perf difference I would guess is because MEFv2 creates dynamic methods for every export (IIRC) whereas VS-MEF's execution path to create an export includes evaluating conditions, etc.

Also: vs-mef is thread-safe and MEFv1 and MEFv2 have known thread-safety bugs. Being thread-safe in a MEF engine requires very careful planning, and it's quite possible that in being truly thread-safe, we have a state machine system that is fundamentally slower than the non-thread-safe one that MEFv2 uses.

[znakeeye]

Not to mention that latest release requires reflection to call GetExportedValue<T>(). When can we expect an updated Nuget package?

[AArnott]

16.3.4-alpha was just pushed to nuget.org. It should be available in less than an hour and includes the new API.

[znakeeye]

@AArnott, I just realized that verifying the assembly timestamps is dead slow. So I need to change my conclusion. vs-mef with a cache is definitely faster than MEF.

[znakeeye]

@AArnott, did you drop support for .NET 4.5.2 in this 16.3.4-alpha version? When updating the nuget package, the package manager tells me this:

Could not install package 'Microsoft.VisualStudio.Composition 16.3.4-alpha'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.5.2', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

[AArnott]

Yes. 16.3 targets net472 and netstandard2.0.
I believe systems with net452 are no longer in the Microsoft support lifecycle, so we're cutting support for it too.