Why is .NET such a memory hog?
-
Why does a simple .NET app with a few forms take more memory to run than apps like explorer.exe and wmplayer? Furthermore, why after closing a form does a .NET app not release the memory used by that form? For extended runtime apps this could pose to be a serious issue. Are there any tips you all could offer on memory management in .NET to make it more efficient? -- Adam "If you can't beat your computer in chess, try kickboxing"
-
Why does a simple .NET app with a few forms take more memory to run than apps like explorer.exe and wmplayer? Furthermore, why after closing a form does a .NET app not release the memory used by that form? For extended runtime apps this could pose to be a serious issue. Are there any tips you all could offer on memory management in .NET to make it more efficient? -- Adam "If you can't beat your computer in chess, try kickboxing"
The same reason its such a processor hog, its interpreted. I'm sure that the garbage collection system will eventually release the memory. I haven't got this far in .net yet but in java I had to implement Object Pools and an ObjectPoolManager to recycle objects. The costs in gc and performance where too high otherwise.
-
The same reason its such a processor hog, its interpreted. I'm sure that the garbage collection system will eventually release the memory. I haven't got this far in .net yet but in java I had to implement Object Pools and an ObjectPoolManager to recycle objects. The costs in gc and performance where too high otherwise.
-
I mean that the CLR converts IL to x86 machine code at runtime.
-
I mean that the CLR converts IL to x86 machine code at runtime.
That's not quite the same - an interpereted language is never compiled at any point, whereas Java and MSIL are compiled to native code at runtime, and can even be turned into a native code exe using ngen.exe .
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
That's not quite the same - an interpereted language is never compiled at any point, whereas Java and MSIL are compiled to native code at runtime, and can even be turned into a native code exe using ngen.exe .
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma GandhiI see. The processor uses esp to sense which instructions to perform from an interpreted language... Interpreted / JIT it is about the same performance hit (in the same order of magnitude anyway)
-
I see. The processor uses esp to sense which instructions to perform from an interpreted language... Interpreted / JIT it is about the same performance hit (in the same order of magnitude anyway)
No, it parses the code and calls predefined methods based on the code. But even if it compiled it (which no doubt some interpreters do), there is a huge difference between parsing text code and reading byte code. You can also easily create a native image from an assembly, which is just a cached native code image of the assembly, and does not need to be JITed.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
I see. The processor uses esp to sense which instructions to perform from an interpreted language... Interpreted / JIT it is about the same performance hit (in the same order of magnitude anyway)
Joey Bloggs wrote: Interpreted / JIT it is about the same performance hit When code is JIT compiled, it will be compiled only once during the execution of the program, regardless of how many times the same code is run (in loops etc.) In interpreted code, the interpretation process is repeated for each loop iteration.
-
Joey Bloggs wrote: Interpreted / JIT it is about the same performance hit When code is JIT compiled, it will be compiled only once during the execution of the program, regardless of how many times the same code is run (in loops etc.) In interpreted code, the interpretation process is repeated for each loop iteration.
I think that that would depend on how much memory is available to the VM. It might need to discard and recompile depending on a wide range of issues.
-
I think that that would depend on how much memory is available to the VM. It might need to discard and recompile depending on a wide range of issues.
-
Why does a simple .NET app with a few forms take more memory to run than apps like explorer.exe and wmplayer? Furthermore, why after closing a form does a .NET app not release the memory used by that form? For extended runtime apps this could pose to be a serious issue. Are there any tips you all could offer on memory management in .NET to make it more efficient? -- Adam "If you can't beat your computer in chess, try kickboxing"
You might want to take a look at this weblog[^] (CLR guy) to understand the pros and cons of the GC. There is also a .NET show with two CLR horses, explaining how it works and why it's by design a "forward allocator". Also of note, the CLR itself is changing from version to version, and may better adapt to stronger requirements. Who knows what's coming next... Taking advantage of InternetExplorer to steal user's name and password. Taking advantage of InternetExplorer to steal user's clipboard.
-
I think that that would depend on how much memory is available to the VM. It might need to discard and recompile depending on a wide range of issues.
Joey Bloggs wrote: It might need to discard and recompile depending on a wide range of issues. IIRC the version of .NET available on your PC does not throw out JITted code. The notion that it does happen is because of early announcements released by MS and at conferences where they were going to make 3 different JIT compilers. That didn't actually happen in time for the framework to go live, so you have two different compilers, the one used by PCs and one used by the compact framework (which does have code-pitching). I thought I remembered someone from MS making a comment to this end, but all I can find is this one[^]. James "I despise the city and much prefer being where a traffic jam means a line-up at McDonald's" Me when telling a friend why I wouldn't want to live with him
-
You might want to take a look at this weblog[^] (CLR guy) to understand the pros and cons of the GC. There is also a .NET show with two CLR horses, explaining how it works and why it's by design a "forward allocator". Also of note, the CLR itself is changing from version to version, and may better adapt to stronger requirements. Who knows what's coming next... Taking advantage of InternetExplorer to steal user's name and password. Taking advantage of InternetExplorer to steal user's clipboard.
I dont understand why people complain when they are lazy (iow using a GC and complaining about it). If all this .NET is so evil, then go ahead and save $100 dollars on some more hardware, and spend a few factors more developing a similar application in a non-GC enviroment. leppie::AllocCPArticle(Generic DFA State Machine for .NET);
-
I dont understand why people complain when they are lazy (iow using a GC and complaining about it). If all this .NET is so evil, then go ahead and save $100 dollars on some more hardware, and spend a few factors more developing a similar application in a non-GC enviroment. leppie::AllocCPArticle(Generic DFA State Machine for .NET);
Only to defend the claims of the original poster, it's true that start time of managed apps is somewhat unusual, the memory usage too. For instance, if all windows services were managed apps, it would require much more time to reboot the machine, even if the services are supposed to be non-blocking. It's probably harder to distribute and sell managed apps today since the end user is not yet used to it. I personally can't see my self distributing a managed app as a shareware, only to expose myself to the deployment problems, plus today's slow start time and memory consumption of managed apps. Taking advantage of InternetExplorer to steal user's name and password. Taking advantage of InternetExplorer to steal user's clipboard.
-
Why does a simple .NET app with a few forms take more memory to run than apps like explorer.exe and wmplayer? Furthermore, why after closing a form does a .NET app not release the memory used by that form? For extended runtime apps this could pose to be a serious issue. Are there any tips you all could offer on memory management in .NET to make it more efficient? -- Adam "If you can't beat your computer in chess, try kickboxing"
I have found that what takes alot of memory is not the classes you create, but the initial .NET CLR runtime. This means that your apps may have a large initial memory footprint, but unless you do something that normally takes a whole lot of memory, the amount of memory will not increase any faster than a C++ application beyond that. As for the speed issues, they are because of JIT compilation. If you want to have fast startup times, run ngen.exe on each of the assemblies in your application. This creates a native image of your assembly, so it does not need to be compiled at runtime. Nish and Rama Krishna did a study on the speed of ngen'ed and non-ngen'ed C#, VB.NET, VB, ngen'ed MC++, non-ngen'ed MC++, mixed C++, etc., and they found that C# is not alot slower than C++ once it has been ngen'ed, because there is no longer the overhead of JIT compilation.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
I think that that would depend on how much memory is available to the VM. It might need to discard and recompile depending on a wide range of issues.
As I said before, if you run ngen.exe on the assemblies, they will no longer need to be JIT'ed at runtime, and therefore, will run much faster.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma Gandhi -
Why does a simple .NET app with a few forms take more memory to run than apps like explorer.exe and wmplayer? Furthermore, why after closing a form does a .NET app not release the memory used by that form? For extended runtime apps this could pose to be a serious issue. Are there any tips you all could offer on memory management in .NET to make it more efficient? -- Adam "If you can't beat your computer in chess, try kickboxing"
If you display forms using
Form.ShowDialog()(shows a modal dialog), you must callForm.Dispose()when you're finished with it. The documentation forForm.ShowDialog()even states this. Managed application are often bigger memory hogs than their Win32 counterparts, but they can also be faster when managed correctly by your code. Keep in mind that most "windows crashes" are usually actually applications' faults (or users - more often users' faults!). Even though the GC will cleanup memory eventually, you must make sure that all references to an object are disposed. After calling Form.ShowDialog, the form is not disposed until you do so manually. When you start throwing controls and strings in multiple collections, you must make sure than no collections still hold a reference to them. If so, the object still exists on the heap and the GC won't clean it up. The reason it is sometimes faster even though it is JIT'd (not interpreted like someone said before - I too get deep into the internals of the CLR and IL) is because of improvements in heap and general memory management - that doesn't necessarily mean smaller memory requirements, unfortunately. I think another reason for large sizes is something I suffer from a lot - overly large assemblies. For instance, in a signed XML app I wrote, I'm forced to use the Microsoft.Web.Services assembly for one class because the System.Cryptography equivalent (using enveloped signatures in this example) doesn't work (at least, not yet). So, the whole Microsoft.Web.Services assembly must be loaded into memory (at least, unlike older implementations of Java, the whole thing isn't JIT'd - just the class I need). This happens quite a bit from what I see. Sometimes making things too easy isn't necessarily a good idea (read "good developers loosing jobs to crappy drag-n-drop VB code monkeys").-----BEGIN GEEK CODE BLOCK----- Version: 3.21 GCS/G/MU d- s: a- C++++ UL@ P++(+++) L+(--) E--- W+++ N++ o+ K? w++++ O- M(+) V? PS-- PE Y++ PGP++ t++@ 5 X+++ R+@ tv+ b(-)>b++ DI++++ D+ G e++>+++ h---* r+++ y+++ -----END GEEK CODE BLOCK-----
-
As I said before, if you run ngen.exe on the assemblies, they will no longer need to be JIT'ed at runtime, and therefore, will run much faster.
"Blessed are the peacemakers, for they shall be called sons of God." - Jesus
"You must be the change you wish to see in the world." - Mahatma GandhiNo, they will *start* much faster. That's completely different from *running* faster. A pre-jitted application is likely to run much slower, since the optimizations done by the JIT compiler won't take place. For details, see Jeffrey Richter's article about JIT Compilation and Performance - To NGen or Not to NGen.
-
I see. The processor uses esp to sense which instructions to perform from an interpreted language... Interpreted / JIT it is about the same performance hit (in the same order of magnitude anyway)
Joey Bloggs wrote: Interpreted / JIT it is about the same performance hit (in the same order of magnitude anyway) Certainly not! The CLR compiles to native code once and then re-uses the native code. It does not throw out any compiled code. Interpreted code is completely different from this. Something you don't mention is that managed code in fact can be much faster: - A managed execution environment can optimize on the specific machine you're running. - There are JVMs that re-compiles code that is frequently run and does more heavy optimizations on that code. - A managed execution environment can do cross-optimization over several assemblies, that weren't even known when designing the application. The above wouldn't be possible in a non-JITted environment. Before your next post, please spend some time learning how the CLR really works! Some good links are: Applied Microsoft .NET Framework Programming Writing High-Performance Managed Applications : A Primer (in the left columns you have several good articles as well) Articles by Jeffrey Richter MSDN Magazine
-
The same reason its such a processor hog, its interpreted. I'm sure that the garbage collection system will eventually release the memory. I haven't got this far in .net yet but in java I had to implement Object Pools and an ObjectPoolManager to recycle objects. The costs in gc and performance where too high otherwise.
Joey Bloggs wrote: haven't got this far in .net yet but in java I had to implement Object Pools and an ObjectPoolManager to recycle objects. The costs in gc and performance where too high otherwise. You're certainly right in that there's a cost involved in using heap memory - in C++, Java as well as C#. If you have objects that are expensive to create and that you frequently need to allocate and deallocate such objects, pooling is a good idea in any language. I wouldn't do it until I saw it was a bottleneck though.