none
Memory usage RRS feed

  • Question

  • Hi, I've noticed that whenever I create a console application in C# using Visual Studio 2010 that it consumes more memory than I would expect. I have created a program with one class and an instance of that class in the main and it seems to increase the memory usage by about 4KB per few seconds and on another program I'm currently playing around with it consumes far more. Is it normal for the memory usage to rise like this on even efficiently created programs or am I producing a few obvious memory leaks. I don't seem to be able to attach my full program with the most memory loss, but this is more of a general question outside of my specific program.

     

    Thanks in advance,

    Paul

    Tuesday, November 15, 2011 4:51 PM

Answers

  • It could be due to how .Net lazily initializes so much. Parts of modules aren't loaded, classes aren't initialized right away, .Net does a lot to not use the memory up front.
    Tuesday, November 15, 2011 5:03 PM
  • Hi Porl91,

    First, we need to ensure whether there is actually a memory leak in the application, then check which causes the memory leak.
    How to Find A Memory Leak.

    Memory Leak Detection in .NET.

    After detecting a memory leak, we can use MemTrack to attempt to isolate the cause of the memory leak in a specified application:
    http://msdn.microsoft.com/en-us/library/ms859419.aspx.

    Have a nice day,


    Leo Liu [MSFT]
    MSDN Community Support | Feedback to us
    Thursday, November 17, 2011 2:40 PM
    Moderator
  • If your program is doing stuff, rather than just idling, then what you could be seeing is just how managed languages deal with memory.

    In code you frequently have variables go out of scope, but they aren't deleted right away.  It is not until the garbage collector runs that the memory is actually freed.  There are also several types of passes that the garbage collector does, some only do a smaller pass to get a good chuck of 'likely to be freed' sections of memory, and other less frequent passes to clean up most everything.  Because of this design, when looking at the program, you will see memory steadily rising, then jumping down a bit every so often, but still slowly going up by more than the jumps down.  Then, even less often, you'll see a more significant jump down in which the whole baseline is lowered.  This will of course be affected by the program itself, as it may be using more/less memory as time goes on, and it is still possible to have memory leaks.

    You can find lots of resources online for more detailed descriptions of how the garbage collector works if you're interested in specifics.

    Thursday, November 17, 2011 4:17 PM

All replies

  • It could be due to how .Net lazily initializes so much. Parts of modules aren't loaded, classes aren't initialized right away, .Net does a lot to not use the memory up front.
    Tuesday, November 15, 2011 5:03 PM
  • I assumed there would be some functionality that would be called as needed, although my program is fairly simple, although it uses loops and class instances so it occupies 12+ KB per few seconds (especially when I perform a few actions quite quickly) and I'm just a bit concerned that it would become an issue if the program kept occupying more space in memory to the point where it affects performance.
    Tuesday, November 15, 2011 5:40 PM
  • Hi Porl91,

    First, we need to ensure whether there is actually a memory leak in the application, then check which causes the memory leak.
    How to Find A Memory Leak.

    Memory Leak Detection in .NET.

    After detecting a memory leak, we can use MemTrack to attempt to isolate the cause of the memory leak in a specified application:
    http://msdn.microsoft.com/en-us/library/ms859419.aspx.

    Have a nice day,


    Leo Liu [MSFT]
    MSDN Community Support | Feedback to us
    Thursday, November 17, 2011 2:40 PM
    Moderator
  • If your program is doing stuff, rather than just idling, then what you could be seeing is just how managed languages deal with memory.

    In code you frequently have variables go out of scope, but they aren't deleted right away.  It is not until the garbage collector runs that the memory is actually freed.  There are also several types of passes that the garbage collector does, some only do a smaller pass to get a good chuck of 'likely to be freed' sections of memory, and other less frequent passes to clean up most everything.  Because of this design, when looking at the program, you will see memory steadily rising, then jumping down a bit every so often, but still slowly going up by more than the jumps down.  Then, even less often, you'll see a more significant jump down in which the whole baseline is lowered.  This will of course be affected by the program itself, as it may be using more/less memory as time goes on, and it is still possible to have memory leaks.

    You can find lots of resources online for more detailed descriptions of how the garbage collector works if you're interested in specifics.

    Thursday, November 17, 2011 4:17 PM
  • If you're running in debug mode the memory management is less agressive because it's assumed that you may want to look at your variables rather than have them disappear.
    Phil Wilson
    Thursday, November 17, 2011 8:47 PM