FastMM: Total Allocated Memory

Question

How could I get the total amount of memory, that allocated by FastMM?

I've tried that:

function GetTotalAllocatedMemory: Cardinal;
var
  MMState: TMemoryManagerState;
begin
  GetMemoryManagerState(MMState);
  Result := MMState.TotalAllocatedMediumBlockSize + MMState.TotalAllocatedLargeBlockSize;
end;

Is it correct?

Anyways it returns something strange. It 5 times less than a value which I can see in Windows task manager. I believe that the amount of memory allocated by a Delphi application equals FastMM allocated memory plus some system overhead. Am I wrong?

Marienthal

What are you comparing to from Task Manager? Tell us the column name, so we can tell you why your results are correct. – Maribelmaribelle

GetTotalAllocatedMemory returns 13,973,184 / taskmanager's "Mem Usage" column now shows 154,912K – Marienthal

Cosmin means to which column in Task Manager are you comparing the result of GetTotalAllocatedMemory? – Delly

"Mem Usage" column on "Processes" page. – Marienthal

Screenshot :) img41.imageshack.us/img41/779/26301229.png – Marienthal

I don't even have a "Mem Usage" column in my Task Manager on Win 7 and on Windows 2008 server. I've got about 9 distinct columns dealing with different aspects of memory usage and it's dynamics. I guess the old Win XP "Mem Usage" was so informative they completely dropped it. – Maribelmaribelle

So the function above is a correct way to get exact amount of memory that allocated by FastMM? – Marienthal

If I were you I'd use FastMM's usage tracker program. – Waft

I would use Sysinternals's VMMap and RAMMap to check memory usage, instead of task manager. They give far more detailed informations. – Breathed

@David @ldsandon I don't need third-party program. I have used Task Manager just to make sure, that my function is working :) – Marienthal

@Roman consider for a minute that the FastMM usage tracker contains source code for how the FastMM authors feel is the right way to report usage. If you want to know how to do it right then I can't see a better source than this. – Waft

I didn't know, that it contains source code. Thank you. – Marienthal

Answer 1

Use this:

//------------------------------------------------------------------------------  
// CsiGetApplicationMemory  
//  
// Returns the amount of memory used by the application (does not include  
// reserved memory)  
//------------------------------------------------------------------------------  
function CsiGetApplicationMemory: Int64;  
var  
  lMemoryState: TMemoryManagerState;  
  lIndex: Integer;  
begin  
  Result := 0;  

  // get the state  
  GetMemoryManagerState(lMemoryState);  

  with lMemoryState do begin  
    // small blocks  
    for lIndex := Low(SmallBlockTypeStates) to High(SmallBlockTypeStates) do  
      Inc(Result,  
          SmallBlockTypeStates[lIndex].AllocatedBlockCount *  
          SmallBlockTypeStates[lIndex].UseableBlockSize);  

    // medium blocks  
    Inc(Result, TotalAllocatedMediumBlockSize);  

    // large blocks  
    Inc(Result, TotalAllocatedLargeBlockSize);  
  end;  
end;

Copal

BTW, this will give you the memory allocated by FastMM only. See another answer to get the process memory usage. – Copal

Answer 2

You are comparing apples and oranges.

FastMM memory is netto usage of memory allocated through FastMM.

This does not include at least these:

• FastMM overhead
• Windows overhead of blocks allocated by FastMM on your behalf
• Windows overhead of things not allocated by FastMM (like the space occupied by DLL's in your process space)
• for GUI apps: overhead of GDI, GDI+, DirectX, OpenGL and other storage for visual objects allocated on your behalf.

--jeroen

You

you forgot the biggest bit which is the memory owned by windows, gdi objects etc. – Waft

that depends if your app is a GUI or not ;-> – You

Answer 3

For the process memory use this:

//------------------------------------------------------------------------------
// CsiGetProcessMemory
//
// Return the amount of memory used by the process
//------------------------------------------------------------------------------
function CsiGetProcessMemory: Int64;
var
  lMemoryCounters: TProcessMemoryCounters;
  lSize: Integer;
begin
  lSize := SizeOf(lMemoryCounters);
  FillChar(lMemoryCounters, lSize, 0);
  if GetProcessMemoryInfo(CsiGetProcessHandle, @lMemoryCounters, lSize) then
    Result := lMemoryCounters.PageFileUsage
  else
    Result := 0;
end;

Copal

What CsiGetProcessHandle does? – Marienthal

A wrapper around the Windows API call GetCurrentProcess – Copal

-1 Because PageFileUsage is NOT the current memory usage. See blogs.technet.com/b/perfguru/archive/2008/01/08/… – Middlings

@A.Bouchez, to say what it is NOT without listing the alternative is a bit lazy – Copal

Answer 4

I also have faced this situation:

Anyways it returns something strange. It 5 times less than a value which I can see in Windows task manager. I believe that the amount of memory allocated by a Delphi application equals FastMM allocated memory plus some system overhead. Am I wrong?

and wasted several hours trying to find out where all the memory is. My app occupied 170 Mb according to Task manager but FastMM's stats was showing total size of allocated blocks ~13 Mb:

12565K Allocated
160840K Overhead
7% Efficiency

(excerpt from FastMM LogMemoryManagerStateToFile procedure output). Finally I realized that this enormous overhead is caused by FullDebug mode. It keeps stacktraces for every allocation so if you've many tiny memory blocks allocated (my app had UnicodeString x 99137, Unknown x 17014 and ~10000 of Xml objects) the overhead becomes frightening. Removing FullDebug mode returned memory consumption to its normal values.

Hope this help somebody.

Shadow

What kind of efficiency do you get when removing FullDebug mode? I moved from 5% to 16%, which is still unacceptably poor IMHO... – Skysweeper

@SlashV I got 1627K Allocated, 4771K Overhead, 25% Efficiency. IDK whether it is good because I have lots of small memory pieces there 617652 bytes: TXmlAttr x 7353 (84 bytes avg.), 429708 bytes: UnicodeString x 9315 (46 bytes avg.), 190860 bytes: Unknown x 2861 (66 bytes avg.), 161704 bytes: TXmlElement x 1394 (116 bytes avg.), 62972 bytes: TXmlAttrList x 1211 (52 bytes avg.) and it's obviously a hard case for efficiency. – Shadow

I figured out that for me the low efficiency was simply due to memory released but not returned to the OS. i.e. temporary objects were created and released before I looked at the overall usage. – Skysweeper