Why is creating an appdomain so expensive?

What are the exact reasons that the creation of an appdomain is so expensive. They share the same heap, the same assemblies etc. What exactly needs to be done by the CLR that comsumes so much resources?

We have seen scenarios where accessing a type/instance from the other appdomain takes up 10 seconds (update: all required assemblies that will be used by both appdomains have already been loaded into the current appdmomain that spawns the new appdomain, except one). Interestingly enough this happens only upon the first access. All subsecent access is very fast.

Update2:

We have attached the VS 2010 sampling profiler and here is the result:

Functions Doing Most Individual Work: System.AddIn.Pipeline.FrameworkElementAdapters.ViewToContractAdapter(class System.Windows.FrameworkElement) Exclusive Samples %43,02

开发者_如何学C

(yes we are using the WPF addin APIs here)

There's a heck of a lot of plumbing that needs to be initialized for an appdomain. Especially since they do not share the same heaps or the same set of assemblies. A detail that's wrong in your question. Their value is in that still costing a lot less than creating a new process.

After seeing edit: 10 seconds is rather a lot and not easily explained away beyond the appdomain doing a cold start on the assemblies that need to be loaded. Disk or network overhead.

This isn't a complete explanation of the problem but a useful tips:

1. Run the application without VisualStudio host (e.g. Ctrl+F5).
2. Use [LoaderOptimization(LoaderOptimization.MultiDomainHost)] attribute on your start-up nethod.

Using these optimizations, the following methods:

FrameworkElementAdapters.ViewToContractAdapter
FrameworkElementAdapters.ContractToViewAdapter

work much faster.