3

I'm finishing up a project, but there seem to be something which is using too much memory. I think there's something that isn't being disposed. And since my program has a LOT of code, I don't feel like going through everything.. There must be a way to see what variable is using what amount of memory during runtime?

Tokfrans
  • 1,939
  • 2
  • 24
  • 56
  • look at all the `new` command with search – SSpoke Mar 01 '14 at 01:32
  • @SSpoke Is this really the only way? – Tokfrans Mar 01 '14 at 01:33
  • Also, though not a production code recommendation, try forcing garbage collection, and then look at how much memory is actually being used. You may just be seeing an aspect of lazy collection. The question then become would do you do to resolve it (if anything) if this is the problem. – Gary Walker Mar 01 '14 at 01:39
  • sounds like you need use a memory profiler, or a debugger like windbg. – John Gardner Mar 01 '14 at 01:40
  • @Tokfrans nope it's not the only way but it's the easiest way you'll find it sooner then you will learning how to use those memory profiling softwares. – SSpoke Mar 01 '14 at 01:41
  • 1
    If it's .net use the redgate memory profiler. They have a free trial that you can use. Start your app up, take a snapshot, let it run for a bit, take another snapshot, compare the diffs. You can see whats being allocated, whats still alive, etc. – devshorts Mar 01 '14 at 01:42
  • 2
    Also counting new's won't do anything @SSpoke. This is C#, not C++. What matters is if things were disposed of, or if they are reachable from root during GC (as purely managed objects). There are alot of ways to create memory leaks in managed, but none of them have anything to do with the amount of things you new up – devshorts Mar 01 '14 at 01:43
  • 1
    @devshorts Ah, very good program. Found it easily!! I would have went with Brian's way but it looked hella difficult! Thank you. – Tokfrans Mar 01 '14 at 01:55
  • My experience has been that if you are in windbg with sos you are having a really bad day. That's like my very last thing, and usually mostly for post crash heap analysis (and even then visual studio can load up a heap and let you inspect the snapshot and the source/threads visually anyways) – devshorts Mar 01 '14 at 01:57

1 Answers1

6

You can look at the managed memory using a debugger such as WinDbg with the SOS extension.

Attach to your process, load SOS using the .loadby sos clr command and inspect the heap using the !dumpheap -stat command. That will tell you the number and type of objects on the heap. From there you can figure out if any of these are taking up more memory than you expected.

This question has relevant information as well.

Community
  • 1
  • 1
Brian Rasmussen
  • 114,645
  • 34
  • 221
  • 317