Loading Classes in Unity

Dec 12, 2014 at 12:31 PM

I wanted to have opinions about a confusion I have:

I have a console executable, where I need to load certain handler classes depending the way the executable is configured in the job scheduler. The decision is made through passing argument to the executable.

Question: Will it be an performance or memory issue if I keep the handler classes within the same project/assembly (with different namespace) as of the executable or should I separate them to separate DLLs ?

The confusion is around the point whether it will be an issue when Unity will try to load the same assembly from which it is running. As the handler and executable is in same assembly. Or unity is intelligent enough to not load the assembly again as it is already loaded as part of the executing exe.
Dec 13, 2014 at 3:00 PM
Whether or not there will be a performance or memory issue is highly depending on the context, so there is only one way to find out: profile! You should do the profiling yourself to see whether this will be an issue in your application.

But in general, there's nothing 'smart' in Unity to prevent assembly re-loading, and there is no need for this, since the CLR will not load the same assembly twice. So there should be no memory leak if you call Assembly.Load for the same assembly many times. There might be a performance penalty in iterating all types in the assembly over and over again, but whether or not this is significant in your case is something you will have to find out for yourself.
Dec 15, 2014 at 2:14 AM
I agree with @dot_NET_Junkie; Unity does not explicitly load assemblies -- this is left to the CLR. The one exception being registration by convention where Unity will load an assembly to determine the types to register (which it doesn't sound like you are using).

Randy Levy
Enterprise Library support engineer
Support How-to