Testing Times: cheap resource monitoring DDT

[Chris Holbrook]

Some time ago I decided to start testing my programs but it takes so long!

Particularly task switching between the application under test and the one which is reporting the memory utilisation, etc. So labour-saving devices have been employed. Here is a very simple one, which can be used in most dialogs which have the standard dialog frame with enough space to display about 30 characters of output. That's right, it overwrites your dialog title with memory and GDI usage fiures every second. Crude or what?

If your code already uses timers, you will have to modify this code!

If you want to be posh, surround these bits of code with #IF ...#ENDIF metastatments.

First, some code to get the current memory used, it could even go in a .INC file but will work inline. I got the declaration from Jose Roca's PSAPI headers on this forum and the function from a Delphi example on the web:

'
TYPE process_memory_counters
   cb                         AS DWORD   '// size of the structure, in bytes.
   pagefaultcount             AS DWORD   '// number of page faults.
   peakworkingsetsize         AS DWORD   '// peak working set size.
   workingsetsize             AS DWORD   '// current working set size.
   quotapeakpagedpoolusage    AS DWORD   '// peak paged pool usage.
   quotapagedpoolusage        AS DWORD   '// current paged pool usage.
   quotapeaknonpagedpoolusage AS DWORD   '// peak nonpaged pool usage.
   quotanonpagedpoolusage     AS DWORD   '// current nonpaged pool usage.
   pagefileusage              AS DWORD   '// current space allocated for the pagefile.
                                         '// those pages may or may not be in memory.
   peakpagefileusage          AS DWORD   '// peak space allocated for the pagefile.
END TYPE


DECLARE FUNCTION GetProcessMemoryInfo LIB "PSAPI.DLL" ALIAS "GetProcessMemoryInfo" ( _
        BYVAL hProcess AS DWORD, _
        ppsmemCounters AS PROCESS_MEMORY_COUNTERS, _
        BYVAL cb AS DWORD _
) AS LONG
'---------------------------------------------------------------------------------
FUNCTION CurrentProcessMemory() AS LONG
    LOCAL tMC AS Process_Memory_Counters

   tMC.cb = SIZEOF(tMC)
   IF GetProcessMemoryInfo(GetCurrentProcess, BYVAL VARPTR(tMC), SIZEOF(tMC)) THEN
       FUNCTION = tMC.WorkingSetSize
   ELSE
       FUNCTION = -1
   END IF
END FUNCTION

Next, some code for message handlers in the dialog callback:

' declarations
    local dwGDIObj as dword
    local lresult as long

' under %WM_INITDIALOG
    hTimer = SetTimer(CBHNDL, 0, 1000, 0) ' 1000 MSecs, change to suit

' under %WM_TIMER
    dwGdiObj = GetGuiResources(GetCurrentProcess(), %GR_GDIOBJECTS)
    lresult = Currentprocessmemory
    DIALOG SET TEXT CBHNDL, "Mem= " + STR$(lresult) +  " GDI OBJs=" + STR$(dwGdiObj)
  
' under %WM_DESTROY
     IF hTimer THEN KillTimer CBHNDL, hTimer

That's it!

[Michael Mattias]

>Some time ago I decided to start testing my programs but it takes so long!

This must be a language thing. I thought we all decided to test our programs the same day we decided we wanted to be a programmer.

As far as testing memory, here's another example:
Add Process Memory Usage Report to any program 1-12-04

That works based on "where we are in the program" rather than on a timer; and although it does not get GUI resources, adding that to the "report line" would be pretty easy*. There's no reason you couldn't write to a log file instead of the screen on the timer notification.

That would give you a complete log file resource usage, if that might be easier to analyze than working from the screen...


* #OPTION VERSION 5 required for both GetProcessMemoryInfo() and GetGuiResources() function.

[Chris Holbrook]

erratum

under "declarations", add:

    LOCAL hTimer as LONG