What's the most efficient approach (App Domain?)...

[Guest]

I'm currently trying to decide the best way to design my application, any
suggestions or comments welcomed.

In C++ to make my apps more efficient (consume less memory while running) I
would break parts of my apps into dll's that I would then load dynamically as
needed. I like this approach for it keeps the memory footprint small. To
use the same approach in C# I've had to load my dll's in separate app domains
that I can later unload to release memory. The problem I'm finding is that
when I load my dll's using the app domain approach, my app seems to use up a
lot of memory when running. This must be due to the overhead of creating the
new app domain.

My question is, would it be better in C# to code all your modules into one
executable? Or create app domains to load separately dll compiled modules?

 

[Jon Skeet [C# MVP]]

I'm currently trying to decide the best way to design my application, any
suggestions or comments welcomed.

In C++ to make my apps more efficient (consume less memory while running) I
would break parts of my apps into dll's that I would then load dynamically as
needed. I like this approach for it keeps the memory footprint small. To
use the same approach in C# I've had to load my dll's in separate app domains
that I can later unload to release memory. The problem I'm finding is that
when I load my dll's using the app domain approach, my app seems to use up a
lot of memory when running. This must be due to the overhead of creating the
new app domain.

My question is, would it be better in C# to code all your modules into one
executable? Or create app domains to load separately dll compiled modules?

Normally, the way to go is to use class libraries rather than having
one mammoth executable, but not create a different app domain for each
library to be loaded into - that creates lots of marshalling etc.

Are your libraries really that huge that you need to unload them? In
most apps, the size of *data* is the important thing, not the size of
the loaded assemblies. Bear in mind that the .NET framework adds a
fairly large overhead itself in terms of loaded assemblies - are yours
really going to be that relevant?

Jon

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

It also have consequence in performance, you will have to marshall
objects. Not a very good idea.

How big are your libraries ?

You can split your code in different dlls , this makes it more manageable.
and reusable also..


cheers,

 

[Nicholas Paldino [.NET/C# MVP]]

Robert,

Using app domains to manage memory is a bad idea, IMO. Not only does it
not really do anything for you (as you have seen), but you also have the
unexpected side effect of having to marshal any objects across the app
domain boundary (either copy them through serialization, or a proxy is
marshaled).

The benefits of app domains are more security and stability related, not
performance related.

While I am not going to say that memory management is not important,
with the runtime already taking a chunk of memory up at the beginning, I
would recommend just setting references and letting the assemblies load in
the app domain you need to use them in. It's not like your app is running
with a small memory footprint to begin with.

Hope this helps.

 

[Guest]

My class libraries mainly consists of related forms that my app would load
accordingly. From your comments I will now load them into the main appdomain
and not worry about unloading them. Thank you for your input.