• 0

[C#] Memory issues


Question

I am a bit concerned about an application i am writing at the moment.

The memory usage keeps going up and up while the program is running. Even when an object is distroyed it doesn't seem to release the memory.

10mb,

20mb,

30mb,

40mb.

Keeps going up the longer i use it.

When i run the program in XP, the memory goes up but goes down to nothing when minimised and back to normal when restored.

10mb,

20mb,

30mb,

40mb,

minimised + restored

memory usage goes back to 20mb

Whats happening here?

Should I be concerned about the memory usage on Vista?

Thanks

post-16640-1243642908_thumb.png

post-16640-1243642947_thumb.png

Link to comment
Share on other sites

15 answers to this question

Recommended Posts

  • 0
I can't see the images, but what kind of program is it?

hmm... can't seem to see them either.

I'll attach them again and see if it works.

Its a educational program i'm designing to teach primary school students.

Its a WPF application written in C#... if that helps

images.zip

Link to comment
Share on other sites

  • 0

If you get a memory leak in a managed language like C#, that means you're keeping references to objects you don't need. The way garbage collection works, an object and everything it uses won't be released as long as you have a reference to that object.

It is normal that when you minimize an application, the memory usage drops; that's Windows freeing up memory for the active applications. The memory isn't really freed, it's temporarly copied to disk.

Link to comment
Share on other sites

  • 0
If you get a memory leak in a managed language like C#, that means you're keeping references to objects you don't need. The way garbage collection works, an object and everything it uses won't be released as long as you have a reference to that object.

It is normal that when you minimize an application, the memory usage drops; that's Windows freeing up memory for the active applications. The memory isn't really freed, it's temporarly copied to disk.

Yea, im aware of that...

If the memory is copied to the disk, how come it only takes a fraction of the memory when restored in XP.

when i run the program it is at 10mb

open a few more forms and memory usage goes to 20mb

30mb

40mb

50mb

60mb

I minimise the application and it goes down to 2mb

but when i restore the application it does not restore the 60mb, it only restores 20mb.

Does the garbage collection kick in when the application is minimised and only restores the true size of the application?

Link to comment
Share on other sites

  • 0

I don't know, maybe someone with better knowledge of these things can help you. In the meantime, you can try experimenting with forcing garbage collection, to see if the increasing memory usage is simply due to "laziness" on the GC's part. Note that this should really be for the sake of experimentation as explicitely calling the GC can ruin your performance.

Edit: you might want to check out the clr profiler, http://msdn.microsoft.com/en-us/library/ms979205.aspx

Edited by Dr_Asik
Link to comment
Share on other sites

  • 0

It's probably memory that's being used for the WPF display. When you minimize it doesn't have anything to draw so it releases the graphics objects then reinitializes them on restore. You may actually see less memory usage under Vista due to the way the presentation foundation interacts with the newer graphics subsystem.

Link to comment
Share on other sites

  • 0

Forcing garbage collection won't do anything as it doesn't mess with the working set size(nor should you). The decrease in memory size is due to the runtime reducing the working set to minimal to free up resources for other apps since your app is no longer focused and doesn't have any background processes doing work. The increase is obviously due to your app allocating more and more objects, whether directly or behind the scenes. Personally, I wouldn't worry about it unless you start getting out of memory issues. The runtime is smart enough with allocation and deallocation. However, if it bothers you that much, running a profiler will be helpful in determining if you have leaks.

Link to comment
Share on other sites

  • 0

I addition to azcodemonkey's comment, you might also try wrapping the objects that use resources in using blocks when they are only short-term objects. That will ensure the CLR calls Dispose() on them when they fall out of scope and queue them for garbage collection.

Link to comment
Share on other sites

  • 0
Forcing garbage collection won't do anything as it doesn't mess with the working set size(nor should you).
Forcing a garbage collection doesn't reduce the memory usage reported by Windows? Yet the GC is supposed to free up any unused memory. I don't get it, could you explain? Thanks.
Link to comment
Share on other sites

  • 0

Forcing garbage collection will only get rid of objects that are marked as finalized and in the GC queue. It can also cause app performance problems.

Link to comment
Share on other sites

  • 0
Forcing a garbage collection doesn't reduce the memory usage reported by Windows? Yet the GC is supposed to free up any unused memory. I don't get it, could you explain? Thanks.

That's correct. It'll clean up objects if necessary, but it doesn't change the reported memory consumption. This is done for a reason. The runtime knows that if memory consumption reached that peak, it is probable it will occur again. It will keep it available for faster allocation. A pointer to the beginning of free memory is maintained so the allocation will always know where to occur in the heap. It's a performance optimization. Over time, if your app reduces the amount of allocations, reported memory usage may shrink.

I believe that the default working set for a 32bit app is 20MB whether your app needs it all or not.

Forcing garbage collection will only get rid of objects that are marked as finalized and in the GC queue. It can also cause app performance problems.

Yep. There is no reason to ever call GC.Collect().

Link to comment
Share on other sites

  • 0
That's correct. It'll clean up objects if necessary, but it doesn't change the reported memory consumption. This is done for a reason. The runtime knows that if memory consumption reached that peak, it is probable it will occur again. It will keep it available for faster allocation. A pointer to the beginning of free memory is maintained so the allocation will always know where to occur in the heap. It's a performance optimization. Over time, if your app reduces the amount of allocations, reported memory usage may shrink.

I believe that the default working set for a 32bit app is 20MB whether your app needs it all or not.

Yep. There is no reason to ever call GC.Collect().

Well, if you're doing something that requires intensive graphics or processor usage it's handy to call it before you start so it is less likely to run during the process. :)

Link to comment
Share on other sites

  • 0
That's correct. It'll clean up objects if necessary, but it doesn't change the reported memory consumption. This is done for a reason. The runtime knows that if memory consumption reached that peak, it is probable it will occur again. It will keep it available for faster allocation. A pointer to the beginning of free memory is maintained so the allocation will always know where to occur in the heap. It's a performance optimization. Over time, if your app reduces the amount of allocations, reported memory usage may shrink.

I believe that the default working set for a 32bit app is 20MB whether your app needs it all or not.

That makes sense, thanks. :)
Link to comment
Share on other sites

  • 0
It is normal that when you minimize an application, the memory usage drops; that's Windows freeing up memory for the active applications. The memory isn't really freed, it's temporarly copied to disk.

I think it's important to distinguish what is meant by the super-vague term of "memory usage".

Virtual: amount of address space (not mem) that the app has reserved for use (much of it may not actually be in use)

Private: amount of that virtual address space that has been "committed" (backed by physical memory or page file)

Private working set: amount of the private memory that is backed by physical memory (vs. page file)

Private bytes are really the best measure of memory usage, and that number doesn't drop when a program gets minimized. The kernel memory manager does trim working sets when apps minimize, and you're right, that's just paging out to disk and should not be regarded as a drop in memory usage; when a system is under heavy memory pressure, the kernel will start to page just about everything out regardless of whether it's minimized, and if you look at that figure, then you will get a really, really distorted picture of memory usage. Process Explorer shows a much clearer picture of memory usage than task manager.

(There is also shared memory and shared working set; e.g., if twenty processes load kernel32.dll, then only 1 copy of kernel32.dll is actually in memory, and all the processes share that; private and shared working sets gives you the total working set. So shared memory doesn't really contribute to your processes memory usage.)

Private bytes can be decommitted and returned to the system only if (1) the application has finished with that particular page of memory (no part of that 4K page is in use) (this first condition is where GC comes in) and (2) if the app decides that it wants to relinquish that page. Sometimes it may decide to hold onto a page a bit longer even though the GC has cleared it of objects so that it doesn't have to reallocate it later. And sometimes, it may not be able to return a page to the system if it has not been fully cleared (this is the problem of memory fragmentation--like disk fragmentation, if you have 100 4-byte objects scattered over 100 different pages, then all 100 pages--400KB of memory--will have to be held open even though you are only using a measly 400 bytes... this isn't a "leak" in the traditional sense because your objects are being deleted).

Edited by kliu0x52
Link to comment
Share on other sites

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.