Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When we add .edmx files to a DLL, the physical size of the DLL increases. DLL's are loaded into memory. However, the .NET infrastructure with functionality such as JIT compilation and the GAC complicates things. Is it true that having a larger DLL automatically increase the memory requirements of an application?

In other words, are memory concerns a good reason to split generated code such as entity framework into N DLL's?

share|improve this question
2  
What code does consumes memory. Not how much code there is. –  Mathew Foscarini Aug 9 '13 at 1:10
    
Does "memory requirements" refer to the total memory used by the app? Supposing a class is instantiated tens of thousands of times and separating it into two removes an instance variable, having more classes in that case would decrease the total memory used. –  John Cartwright Aug 9 '13 at 6:01
1  
@MatthewFoscarini - Are you saying there is no direct correlation between the physical size of a DLL and how much memory loading said DLL into the appdomain consumes? –  P.Brian.Mackey Aug 9 '13 at 14:11

1 Answer 1

Of course, the more code you have in the application, the more memory it requires to load all that code when running the application. But

In other words, are memory concerns a good reason to split generated code such as entity framework into N DLL's?

I would say no. Modern day computer should have more that enough memory to load all the executable code at once. There could be an issue with run-time memory, e.g. if you were to try to cache all the data for an enterprise application in memory. But not the executable code, IMHO.

And splitting it up into several DLLs would not help a lot. You would still require to load all the executable code in order for the application to work. Except if you would load/unload code on demand.

And trying to load/unload code on demand does add extra complexity to the project. This complexity adds cost and risk (which is more cost). E.g. you cannot simply unload a dll in .NET. You have to load it into a separate AppDomain. Then you can unload the AppDomain.

If you really was hitting the memory limit for executable code, upgrading the memory on the computers running the application would most probably be cheaper than implementing loading/unloading of code at runtime.

share|improve this answer
2  
"Modern day computer should have more that enough memory to load all the executable code at once." That kind of advice waxes and wanes. Yes, laptops and desktops have multiple GB, and servers much more. But phones and similar devices are much more constrained. –  Ross Patterson Aug 9 '13 at 11:00
1  
+1 for "And trying to load/unload code on demand does add extra complexity to the project.". It's how things were always done 40 years ago, when we thought 32KB was a lot of memory, and every program was designed to run in phases and load and unload parts dynamically. It caused a lot of problems that were solved by virtual memory and large physical memory banks. –  Ross Patterson Aug 9 '13 at 11:02
    
"You would still require to load all the exe..." Enterprise systems have many databases. A given application may only use a small subset of them. –  P.Brian.Mackey Aug 9 '13 at 12:23
    
@P.Brian.Mackey: Yeah, databases. The key there is data. That's not the same thing as code, Lisp notwithstanding. –  Mason Wheeler Aug 12 '13 at 14:14
    
@MasonWheeler - My point is that ORM's generate code from a database. If I don't use that generated code, then how much does that unused code (In this case a generated ORM mapping to a set of DB's) impact a .NET application? This answer does not address this critical point in my question. –  P.Brian.Mackey Aug 12 '13 at 14:21

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.