views:

76

answers:

1

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

(yes we are using the WPF addin APIs here)

+2  A: 

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.

Hans Passant
It is exactly this "heck of a lot of plumbing" that I am intersted in.
bitbonk
Managed heap is per process all AppDomains all share the same managed heap.
bitbonk
If you really want to find out then you can by studying the SSCLI20 source code. Fair warning: the appdomain and fusion related code is dense as a brick and there's a lot of it.
Hans Passant
No, keeping the heaps separate is what appdomains are all about.
Hans Passant
Why do they not share the same assemblies? The appdomain is created in the same process where all assemblies habe allready been loaded.
bitbonk
Review the docs for the AppDomainSetup.LoaderOptimization property. But you'd normally use an appdomain to run *different* code. Some SQL/CLR query, an ASP.NET web page request, a plug-in.
Hans Passant
Do you have any MSDN docs or any other reference material stating that appdomains have their own heap? If each app domain had it's own heap, then wouldn't I have to see a GC.Collect where I can pass the appdomain instance?
bitbonk
GC.Collect is a time waster. You tried removing that call why you have one of those things in place?
WeNeedAnswers
I am not using it at all. I am just trying to figure out how the managed heap works in respect to appdomains.
bitbonk
plot thickens....
WeNeedAnswers
10 seconds is an awful lot of time, whats your network stack doing when these appdomains are firing, sounds like a call thats not returning in a timely fashion. I got the big delay when moving code from a standalone box over to network, the appdomain stuff was making calls, I narrowed it down to security.
WeNeedAnswers
There is no network and no disk-IO involved when accessing the cross appdomain instance. It is all CLR "overhead" somehow. The app itself contains no code that does disk-IO or networking.
bitbonk