3

My Delphi XE application is based on a single EXE using a local server DLL created by RemObjects and uses a lot of memory for a specific operation until it generates an exception saying there are not enough memory. So I'm trying to understand why and where this is happening so I placed various steps throughout my code where I report on memory usage. The problem is that I'm getting very different information based on the method used to get memory usage information:

  1. If I use the method explained here which asks FastMM directly for both the Client EXE and Server DLL, here is what I get:

    • STEP 1: [client] = 36664572 - [server] = 3274976
    • STEP 2: [client] = 62641230 - [server] = 44430224
    • STEP 3: [client] = 66665630 - [server] = 44430224

  2. Now if I use the method explained here which uses GetProcessMemoryInfo, I get far more memory usage:

    • STEP 1: [process] = 133722112
    • STEP 2: [process] = 1072115712
    • STEP 3: [process] = 1075818496

It looks like second method is the right based on my memory problems but how could the FastMM method be so "low" ? And what can explain the difference ?

Community
  • 1
  • 1
jonjbar
  • 3,896
  • 1
  • 25
  • 46

1 Answers1

5

GetProcessMemoryInfo also reports memory that is not managed by FastMM, like memory that is allocated by the various non Delphi dlls you might call (like winapi).

Also FastMM can allocate more memory from Windows that your application actually uses for internal structures, fragmentation and pooling.

And as last, with GetProcessMemoryInfo you measuring the Workingset size. That is what part of the application's memory currenctly in RAM instead if in the page file. It includes more than just data structures and is definately not comparable to the total memory the application has allocated. PagefileUsage would be more comparable. Workingset size almost never is what you are looking for. See here for a better explanation.

So they both give different results because they both measure different things.

Community
  • 1
  • 1
Lars Truijens
  • 42,837
  • 6
  • 126
  • 143
  • Thank you for your answer. It looks like in my case, Workingset size is what I'm looking for as memory consumption reported by FastMM is low and doesn't explain my out of memory exception. Any idea if and how I can have more details about the Worksingset and what is causing its huge size ? – jonjbar Mar 15 '12 at 08:43
  • 1
    The point I tried to make is that the Workingset size is not what you should be looking at. Minimize your application and see how the Workingset size is so low it can't be the memory your application is using. Please post new questions as questions if you have any. – Lars Truijens Mar 15 '12 at 09:38
  • Thanks Lars but I've tried to minimize the application and focus another one and reported memory usage by GetProcessMemoryInfo is still as huge as before. So it looks like this is what I need to analyze and understand. Do you agree ? If so, I'll follow your advise and post another question. – jonjbar Mar 15 '12 at 10:24
  • 1
    No if you look at PROCESS_MEMORY_COUNTERS.WorkingSetSize, yes if you look at PROCESS_MEMORY_COUNTERS.PagefileUsage – Lars Truijens Mar 15 '12 at 12:05
  • Thanks again Lars, PageFileUsage is what I'm using. Here is the follow-up question if you'd like to step in: http://stackoverflow.com/q/9720943/184404 – jonjbar Mar 15 '12 at 13:45