MEF - Performance Characteristics

Oct 4, 2008 at 3:34 PM
Edited Oct 5, 2008 at 6:44 AM
G'Day,

Firstly, thanks for sharing MEF with the community and secondly for changing the license to MS-PL.

I notice you've said MEF is geared towards applications like Visual Studio, which I imagine suggests the performance characteristics of MEF will be high.  I've experimented with dynamically loading modules / plugins from directories before (we use CAB in a large, enterprise application), and performance is typically terrible if using straight reflection.  I've looked at Mono.Addins, and their approach is very interesting, whereby they spawn a process to analyse a directory of assemblies and build a local database of the reflected metadata.  By spawning a separate process, it relieves the host application of all the memory required to reflect over the assemblies.  They hash the cached metadata for each assembly with version information to know when to re-analyse.  

Is MEF going to take a similar approach such as cache metadata?  Additionally, do you have plans to generate a 'composition' program from a given set of reflected assemblies (that is, generate IL that builds up a composed program from a set of metadata).  It seems fair to assume the process of composition will remain fairly static for a given set of assemblies.  What would be great is to be able to pre-generate the program as an assembly, similar to Xml Serialization does with sgen.  e.g. MyProgram.exe and the generated MyProgram.Composition.dll.

This approach is used in Unity, to generate a build plan, which uses LCG to compose a given type.  I've performed some micro-benchmarks and found it to be very performant.

Cheers,

Stu

Oct 4, 2008 at 3:46 PM
Hey Stu!

I cannot speak to the actual plans (since I don't work for Microsoft). I wanted to confirm your post in two ways:

First your line of reasoning is very sound and I can see that you know exactly what you're talking of. You couldn't be more right in your thoughts where it comes reflection and performance. Especially naive reflection that isn't cached. This was the case in the original ObjectBuilder and it was not an oversight but a YAGNI approach to creating this DI container that lead down this path.

Second; I see several code bases moving in the direction of code generation today! It seems to be the wave of the future. Even hints to such things as a new keyword 'dynamic' in C# 4.0 speaks to this being an important trend. In point of fact I speak on the topic "Dynamic Code" at this year's version of Øredev so the area is very dear to me.

We can only hope this is the path that MEF and similar products will take and it is people like you that push in this (the correct) direction! Keep it up!

Cheers,

/Magnus
Techie.notepad

On Sat, Oct 4, 2008 at 17:34, scarnie <notifications@codeplex.com> wrote:

From: scarnie

G'Day,

Firstly, thanks for sharing MEF with the community and secondly for changing the license to MS-PL.

I notice you've said MEF is geared towards applications like Visual Studio, which I imagine suggests the performance characteristics of MEF will be high. I've experimented with dynamically loading modules / plugins from directories before (we use CAB in a large, enterprise application), and performance is typically terrible if using straight reflection. I've looked at Mono.Addins, and their approach is very interesting, whereby they spawn a process to analyse a directory of assemblies and build a local database of the reflected metadata. By spawning a separate process, it relieves the host application of all the memory required to reflect over the assemblies. They hash the cached metadata for each assembly with version information to know when to re-analyse.

Is MEF going to take a similar approach such as cache metadata? Additionally, do you have plans to generate a 'composition' program from a given set of reflected assemblies (that is, generate IL that builds up a composed program from a set of metadata). It seems fair to assume the process of composition will remain fairly static for a given set of assemblies. What would be great is to be able to pre-generate the program as an assembly, similar to Xml Serialization does with sgen. e.g. MyProgram.exe and the generated MyProgram.Composition.dll.

This approach is used in Unity, to generate a build plan, which is essentially an dynamic method / IL that composes a given type. I've performed some micro-benchmarks and found it to be very performant.

Cheers,

Stu

Read the full discussion online.

To add a post to this discussion, reply to this email (MEF@discussions.codeplex.com)

To start a new discussion for this project, email MEF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Magnus Mårtensson
Senior Consultant - Scrum Master - MCSD, MCTS
Dotway AB

Tel: +46 (768) 51 00 36

http://blog.noop.se/
Oct 4, 2008 at 4:18 PM

Hi Stu

MEF uses catalogs as the discovery mechanism for locating composable parts which carry imports and exports. We are working on a catalog caching mechanism that caches all of the metadata. With the cache in place, we will not be continually reflecting over assemblies. The cache also supports lazy-loading, meaning that assemblies will not get loaded until the types are actually instantiated.

As far emitting IL to compose the graph, this is not something we are doing currently. Performance with MEF is critical, so we will be evaluating various techniques to get our perf to acceptable levels.

Thanks!

Oct 5, 2008 at 7:05 AM
Hi Magnus,

You are absolutely correct, with regards to OB in CAB, as I spent several days adding caching to a number of the builder strategies to improve our WEB application performance.  Using dotTrace, I identified that calls to OB were scattered throughout our top 20 hot spots (including the top 3), which is amazing when you consider that our app is also communicating heavily with a database and this was 'only' the 4th hot spot.  Post optimizations, OB completely vanished from the top 20.

Code generation is one aspect of .NET that makes it a very powerful platform.  As an example we've seen it put to great use in many of the dynamic languages available on .NET today, some DI / IoC frameworks (for build-up) and even in some parts of NHibernate.  On a side note, it is interesting to see the technique of dynamic code-gen come to the business world, as I recall writing self modifying and self generating code back in the late 80's / early 90's in assembler.  One example was to generate a routine that rendered a transparent sprite to the video buffer on a PC, for maximum performance.

I haven't seen references to the new 'dynamic' keyword, or any information on C# 4.0 yet; however, my quest begins.

Cheers,

Stu