application uses all the memory
-
i have an application which has a 2 MB .exe. but when it runs it uses the 21 MB of the primary memory. Before initialization of the forms it already uses 13-14 MB (in release mode).after main form loaded it bocomes 21 MB. Because i use dynamic binding when using class i don not think that it is because all project loding at start up. i think it is because of .net framework loads itself before. have any idea how can we decrease this use amount?
-
i have an application which has a 2 MB .exe. but when it runs it uses the 21 MB of the primary memory. Before initialization of the forms it already uses 13-14 MB (in release mode).after main form loaded it bocomes 21 MB. Because i use dynamic binding when using class i don not think that it is because all project loding at start up. i think it is because of .net framework loads itself before. have any idea how can we decrease this use amount?
Of course the .NET Framework is loaded before your app! What do you think managed your managed code? This is a runtime, just like Java required a JRE, VB requires the VB Virtual Machine (VM), etc. The CLR will take a few megs but the assemblies that are loaded into your application will take as much space as required to execute the code. The CLR JIT's only what is linked as it executes code, so it all isn't JIT'd at once (JIT-on-demand). In fact, an unmanaged AppDomain is created that loads the CLR and creates a managed AppDomain, then your executable is loaded into that AppDomain along with any dependent assemblies. It has to be loaded first or your application doesn't run. How can you reduce memory? For once, implement a clean design. Close handles, dispose disposable objects, dispose modal forms (when you call
ShowDialog) when you're finished with them. Use structs (allocated on the stack instead of the heap) when you need information on a short-lived duration (like aSystem.Windows.Forms.Messageis used only for the current message, so there's no need to allocate it on the heap). All the things that computers science (or experience) should teach you.Microsoft MVP, Visual C# My Articles
-
Of course the .NET Framework is loaded before your app! What do you think managed your managed code? This is a runtime, just like Java required a JRE, VB requires the VB Virtual Machine (VM), etc. The CLR will take a few megs but the assemblies that are loaded into your application will take as much space as required to execute the code. The CLR JIT's only what is linked as it executes code, so it all isn't JIT'd at once (JIT-on-demand). In fact, an unmanaged AppDomain is created that loads the CLR and creates a managed AppDomain, then your executable is loaded into that AppDomain along with any dependent assemblies. It has to be loaded first or your application doesn't run. How can you reduce memory? For once, implement a clean design. Close handles, dispose disposable objects, dispose modal forms (when you call
ShowDialog) when you're finished with them. Use structs (allocated on the stack instead of the heap) when you need information on a short-lived duration (like aSystem.Windows.Forms.Messageis used only for the current message, so there's no need to allocate it on the heap). All the things that computers science (or experience) should teach you.Microsoft MVP, Visual C# My Articles
Is it possible that in future releases of Windows, the CLR would be started as system starts and manage all dotNET applications? It seems that currently every single dotNET app loads a copy of the CLR into memory even when they are executed concurrently
-
Is it possible that in future releases of Windows, the CLR would be started as system starts and manage all dotNET applications? It seems that currently every single dotNET app loads a copy of the CLR into memory even when they are executed concurrently
The CLR would be started with various system components in "Longhorn", but that won't change your program's behavior. The CLR - the runtime for managed code - is loaded for each app. This - like all runtimes - helps protect the other programs using the runtime and the operating system as well from each other. If your program was to crash and tear down the CLR, I definitely don't want it taking down mine or crashing the OS. This can even be done without crashing - a call to
Environment.Exitunloads the CLR and quits the application immediately, regardless of any running threads.Microsoft MVP, Visual C# My Articles