| "Brian Gideon" wrote:
| > When I start an empty
| > windows application it consumes more than 8MB (as shown on the vm usage
| > column in task manager). That's perfectly normal.
|
| Empty app uses 8 MB? it's a hog.
|
| I've just tried a very small C# console app on XP-64. It takes 13 MB!
| On that machine:
| Windows Explorer uses 32 MB
| wmiprvse - 7.5 MB
| Most of system tasks are under 8 MB.
|
| Isn't this a bit worrying?
|
Not at all, who tells you that Explorer written in C# would use that much
more? (say 48MB)
The same for wmiprvse, which is a do nothing service as long as you are
using WMI from a client application, I've seen this service consuming >
300MB.
The point is that managed applications have a larger "base memory footprint"
when compared to native applications, this is the result of the CLR loading
a set of initial assemblies and the GC heap. A "complex" console application
won't take that much more than 8 -10MB, what really take memory are the data
structures (the objects allocated from the heap), and this is where the
problem is.
The framework makes it easy to over-consume, it doesn't force you to think
about memory consumption when selecting your containers, this is
fundamentally different from low level code like C where you are forced to
think about "efficient data structure usage" because you have to define them
yourself. Using C++ and STL containers tend toward over-consumption as well,
but as most C++ programmers have a C background, they have the natural
reflection to think about efficiency when selecting containers and
algorithms.
Note that I don't mean to say that you can author an application in managed
code that is as efficient when it comes to memory consumption as it would
have been written in C, you can't, you will always consume at least a few MB
more.
There is the managed environment (GC heap, large framework libraries)
overhead and the "everything is an object" overhead you need to accept, if
you can't, you have selected the wrong development platform and you need to
go back to unmanaged, but be prepared to spend a hell of a time to think
about efficient memory allocation/de-allocation, not to mention the
algorithms and the implementation of the functionality available in the
framework.
Willy.
