forums.silverfrost.com

[sparge]

A last-thing-before-going-home-for-the-weekend thought. I have had occasion today to scrutinize closely the "system footprint" one of my FTN95-built apps that was - ahem - causing difficulty on an (admittedly pitifully underspec) machine, having always behaved itself well on all machines it has been run on to date. I used an application called TaskInfo2002 for this purpose. I was rather taken aback to discover that my app had approximately 270 MB of virtual memory associated with it. This is at the stage where it first posts the main window, before it actually does anything resource-hungry. This prompted me to look at a couple of other FTN95 system tray apps that I have written; these have approximately 180 MB and 280 MB of virtual memory associated with them. Same whether I run debug or release mode builds.

It's not like these apps use huge multidimensional arrays or anything. The system tray apps in particular use trifling amounts of data storage. The exe for one is only 40 kB.

Some comparisons:

- MS Excel with a spreadsheet open, 70MB
- MS Word with a document open, 230 MB

So my question is ... how can my apps, particularly the "trivial" system tray ones, require as much virtual memory as they do? Is it a consequence of the "use clrwin" statement? Is this a sledgehamer to crack a nut in general?

Andy :confused:

[Anonymous]

Andy

'Virtual Memory Size' and the amount of memory your program uses are not really related. The Virtual Size is the size of all the bits that the application uses all added up. Most of these bits are parts of the Operating System and have allocated the virtual memory long before you programs runs and will still hang on to it long after your program has exitted. For example, I ran sdbg and it has a virtual memory footprint of 189MB. However, it is only using 4.7MB. The rest is made up of:

SHELL32.DLL - 8MB
MSHTML.DLL - 3MB
MSI.DLL - 2.8MB
SALFLIBC.DLL - 1.9MB
NETSHELL.DLL - 1.7MB
GDIPLUS.DLL - 1.7MB

And so it goes on... you can see the list by using a dependency walker. With the exception of SALFLIBC the others are all part of the OS.

[sparge]

Robert,

Fair enough as far as it goes - as an explanation of the principle of the thing - but it's not like my programs are heavily WinAPI-dependent. The system tray applet I mentioned uses winio@ - and that's it. But it USEs clrwin. My question is, I suppose, is my app hooking into a mountain of stuff that it never actually uses as a result?

I'm looking at the task list in TaskInfo at the moment. My two system tray applets are associated 273 MB and 177 MB. The next one that comes close is that Lancaster bomber of apps, Lotus Notes, and even it has only 140 MB associated. Then it's Symantec anti-virus (100 MB), Internet Explorer (75 MB). No way is my silly little applet hooked into twice as much OS stuff as Lotus Notes ...

The thing that's bothering me is whether a humungous virtual memory footprint has any implications for trying to run the associated app on a machine with very little physical memory. I have some unexplained behaviour from last week, on a machine with only 32 MB of RAM - the app drives a scanner, and the PC kept rebooting mid-scan after between one and five succesful scans - and I would like to know whether this might be to do with the huge mismatch between physical memory and virtual memory footprint. I should add that i) this app is mature now, it's been running for five years on a number of machines with no problem like this before, and ii) I ran an exhaustive set of memory diagnostics on the rogue PC and came up with nothing, so faulty memory is not the issue.

Andy

[sparge]

Sorry for bad form of posting two replies to your one ... I still don't get this. I looked at MS Word and my two apps under Dependency Walker, and added up all the DLL sizes, and looked at the virtual memory footprint while doing this - the numbers just don't add up:

MS Word: DLL sum, 42 MB; virtual memory footprint, 270 MB
My app 1: DLL sum 19 MB; virtual memory footprint, 280 MB
My app 2: DLL sum 19 MB; virtual memory footprint, 180 MB

So is the discrepancy made up of dynamic memory allocated by each of the DLLs? And if this allocation is done before anything actually runs, am I right in inferring that if I knew how much virtual memory was allocated by each DLL, I could make the numbers add up (to within exe size) as follows:

Denote by VMA(j) the virtual memory allocated by DLL(j)
Denote by VMF(i) the virtual memory footprint of application(i)
Denote by used(i,j) a variable equal to 1 if DLL(j) is used by application(i), and equal to 0 otherwise

VMF(i) = sum_over_j (used(i,j) x VMA(j))

Is this getting anywhere closer to the truth?

Andy

[Anonymous]

After reading your post I realised I had made an error. I used the depends and took an export to add up the amounts. However the export was for the whole of Windows and not sdbg :confused: I'll have to look into this further.

[sparge]

Hi Robert,

Thanks for coming back on this. I'm still interested in the answer, but more from a pure learning PoV now. I have established the following facts:

i) the virtual memory footprint is extremely machine-dependent. I installed TaskInfo on the rogue machine and the Salford app I was worried about had a footprint of just 16 MB on that machine (c.f. ~250 MB on my main machine). So the situation was not at all a 250 MB virtual memory app trying to wriggle about in 32 MB of physical RAM, as I had assumed.

ii) The rogue PC that kept rebooting really was flaky, even if it wasn't a physical memory problem. After step i above, I transplanted extra memory into it, and even with 192 MB it still exhibited the same symptoms. I tried the same app on two other Win98 machines with only 128 MB and it kept going all day on both.

So it would appear that virtual memory footprints are loosely related to the physical memory available. This said, it still appears to be the case that on a specific machine, Salford ClearWin apps have huge amounts of virtual memory associated with them compared to other genuinely bloated apps that I would expect to be top of the list - and this still seems to me to be an inherently Bad Thing if there's no (good) reason for it.

Andy

[Martin]

I would guess that the virtual memory readout in TaskInfo is the amount of virtual address space within the process that has been reserved, rather than the amount of memory actually allocated for use. Each process has 2GB of addressable virtual memory. When a block of address space has been reserved it will not be available to other memory allocation systems in the process. Reserved address space will not take up any space in your physical memory until it is committed (allocated). Even then I believe it would have to be used (i.e. written to) before the OS maps it to physical memory.

The FTN95 run-time library uses it's own memory allocation system for some things and I believe that it attempts to reserve a large amount of address space at startup for efficiency. If it cannot reserve the amount it requests, it will reserve as much as the system will allow. This may account for the differences in TaskInfo's virtual memory readout you are seeing between machines. As far as I know, this system should not cause any problems or slow-downs and is simply it's way of managing memory.

Martin

[sparge]

That's a very helpful explanation, Martin. Many thanks. Andy