How fast is AppDomain creation?

Question

I have just discovered that if generating assemblies via Reflection.Emit, the .NET framework keeps references in a static member that prevents Reflection.Emit classes not to be GC'ed.

I cannot use DynamicMethod due to limitations. I also generate a lot of assemblies (incremental compiler of IronScheme) over the course of a program (could be 1000+).

Hence, I was thinking to just handle the code generation in a separate domain, and unload it later (have not decided how to handle this).

Does anyone have any experience how expensive this would be?

Answer 1

As I understand it, it's just a little slower than spawning a thread.

---

Been doing some research, trying to find a real reference for this. So far, this is the best I can come up with:
http://msdn.microsoft.com/en-us/library/aa159887.aspx

About 2/3 of the way down it calls creating AppDomains "expensive", but then you might say the same about threads in certain contexts- it really depends on what the particular thread does at creation.

Again: it's my understanding that an AppDomain is essentially a thread (or multiple threads) within a process — a logical delimiter, if you will — such that the run-time guarantees certain additional protections are in effect that prevent separate AppDomains from interfering with each other. To create a new AppDomain within an existing process (application) the framework has to do all the work associated with creating a new thread, plus some additional overhead to set it up within the rest of the applicaion (that may also involve loading one or more assemblies into memory). In the end, an AppDomain lives somewhere between a thread and a process.

Answer 2

I would benchmark it for your specific case.

If it turns out to be expensive, just pre-create a few of them, use then as needed and recreate new ones in the background to make sure you always have enough unused ones waiting (a bit like a thread pool, but you recreate them every time to free up the memory).