views:

267

answers:

1

I have an application which I've developed which queries Active Directory information and stores about 15 properties into a Datatable which is kept in memory.

I need to decrease the amount of "Commit" memory it is setting aside.

The application stays active in the system tray and allows for quick searching of information along with pictures for users.

I have a class, which is able keep memory usage down pretty low. It runs on a timer every 10 seconds and listed below:

Public Class MemoryManagement

    Private Declare Function SetProcessWorkingSetSize Lib "kernel32.dll" (ByVal process As IntPtr, ByVal minimumWorkingSetSize As Integer, ByVal maximumWorkingSetSize As Integer) As Integer

    Public Shared Sub FlushMemory()
        GC.Collect()
        GC.WaitForPendingFinalizers()
        If (Environment.OSVersion.Platform = PlatformID.Win32NT) Then
            SetProcessWorkingSetSize(GetCurrentProcess().Handle, -1, -1)
        End If
    End Sub

End Class

After the application loads the Task Manager shows the following:

Working Set(Memory) - 30,000K
Memory(Private Working Set) - 13,000K
Commit Size - 25,000K

and after a few seconds the Memory Management class will reduce memory usage to:

Working Set(Memory) - 700K
Memory(Private Working Set) - 600K
Commit Size - 25,000K

One thing I've noticed is that the Commit Size never goes down and in fact will continue to grow (very slowly) over a few days. After two days it got up to 36,000K for the Commit Size.

Now I'm pretty positive I'm disposing all the objects that allow a dispose method and setting other objects to = nothing.

If I look at the Task Manager other applications don't have such a large footprint for the Commit Size.

Any ideas on how to further trim the commit size my application is setting aside?

Edit:

Per the suggestion below I've included some of the info from CLR Profiler below:

Summary for CSIDir.exe
Allocated bytes: 15,097,943
Relocated bytes: 3,680,460
Final Heap bytes: 1,612,611
Objects finalized: 16,194
Critical objects finalized: 148
Gen 0 collections: 19
Gen 1 collections: 17
Gen 2 collections: 16
Induced collections: 16
Gen 0 Heap bytes: 769,019
Gen 1 Heap bytes: 156,141
Gen 2 Heap bytes: 947,492
Large Object Heap bytes: 40,706
Handles created: 4,664
Handles destroyed: 4,386
Handles surviving: 278
Heap Dumps: 1
Comments: 0

+1  A: 

I suggest you to use profiler tools to see how your objects are actually allocated and destroyed. One such profiler for VB.net is CLR profiler from MS. The description of the profiler says:

The CLR Profiler includes a number of very useful views of the allocation profile, including a histogram of allocated types, allocation and call graphs, a time line showing GCs of various generations and the resulting state of the managed heap after those collections, and a call tree showing per-method allocations and assembly loads.

AlexKR
I've updated my original post with some information from the CLR Profiler.It provides a substantial amount of data and I'm not familiar enough with the application to interpret it that well.
JoshF