| 1) What would be the runtime RAM requirements for a managed application
| compared to similar application unmanaged. Will there be more RAM required
| because it is managed application, say simple application like 'Hello world'
| which is not using any stack or heap variables.
Yes, the memory consumption of .NET applications is somewhat higher than a
native application. The reason for this is that the run-time ust be loaded
before any managed code can run, the amount of memory that isneeded is
highly dependent of the type of application, but in general one can say that
such app. consumes some 5 - 10 MB more than it's unmanaged equivalent.
| 2) If I install .Net frame work 1.1 or 2.0 and donot run any managed
| application, will the .Net frame still use any RAM?
No.
| 3) Please direct me to any links that explain RAM or processor overhead
| because of running a managed application or simply because of installing .Net
| framework.
Google can be helpfull to find some of these resources, but basically all
you need can be found on Microsoft's MSDN site.
Willy.
Raj - 11 Jan 2006 19:31 GMT
Thanks for the detailed reply.
I guess this managed overhead is constant after all managed components are
loaded even if we keep adding more and more managed Applications or windows
services.
> | 1) What would be the runtime RAM requirements for a managed application
> | compared to similar application unmanaged. Will there be more RAM
[quoted text clipped - 23 lines]
>
> Willy.
Willy Denoyette [MVP] - 12 Jan 2006 16:00 GMT
Not really, the CLR is loaded per process, while a lot of the framework code
is shared amongst managed processes, your code is not (unless you ngen'd
your assemblies).
Willy.
| Thanks for the detailed reply.
|
[quoted text clipped - 29 lines]
| >
| > Willy.
Raj - 31 Jan 2006 19:21 GMT
1) Is the .text area not shared even when same application(same version) has
more instances like two processes for same application.
2) Is it same with unmanaged Win32 applications also? Only Dll text is
shared?
thanks,
Raj
> Not really, the CLR is loaded per process, while a lot of the framework code
> is shared amongst managed processes, your code is not (unless you ngen'd
[quoted text clipped - 43 lines]
> | >
> | > Willy.