in reply to Memory requirements for a Win32 GUI

Firstly, the Task Manager, or whatever tool you are using to measure the memory is doing you a disservice. It is showing you the total amount of physical RAM being consumed by the app, including all the ReadOnly, ExecuteRead, WriteCopy segments which are shared between all running copies of the application.

Note: I'm assuming that Terminal Server shares dlls between sessions.

What that means is starting the first copy of an app will consume the amount of memory shown. But starting a second and subsequent copies, a large proportion of that "Working Set Allocation", will be shared between those copies and so consume no extra physical RAM. It will simply be mapped into the memory space of each copy of the app.

The Win32::GUI app will always consume least memory. In part, because most of the code it uses is already loaded (User32.dll, GDI.dll) for use by systems apps. In part because, it is just a thin wrapper over those system dlls, whereas the other two have whole rafts of platform independant interfaces layered on top of the system dlls.

It's also worth noting that with Win32::GUI, adding complexity to your user interface, extra windows and dialogs, will have little effect on the memory consumption, because you already loaded all the code (GUI.dll). Whereas with for example Tk, each new type of component you use will require another dll to be loaded.

The best way to determine the extra physical ram consumed by an app is to note the Physical Memory Available (Performance tab of the Task Manager) when you've loaded one copy, start a second copy and note it again. That will give you the cost of each new copy which will be considerably less than the headline figure attributed to the app.

For Win32::GUI apps, it comes out at around 3.5MB per copy on my system. Not trivial, but 30x3.5 is better than 30x6.9 :)

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Replies are listed 'Best First'.
Re^2: Memory requirements for a Win32 GUI
by pvbcharon (Beadle) on Apr 14, 2008 at 12:47 UTC
    Thanks, BrowserUk.
    Note: I assuming that Terminal Server shares dlls between sessions.
    I don't think it does... AFAIK, the sessions on a Terminal Server are completely separate and don't really reuse anything.
    The best way to determine the extra physical ram consumed by an app is to note the Physical Memory Available (Performance tab of the Task Manager) when you've loaded one copy, start a second copy and note it again. That will give you the cost of each new copy which will be considerably less than the headline figure attributed to the app.
    Sounds reasonable ;o) I'll have a look at that number and see if the numbers look better. That's all a little hard to test without actually pushing an app out to the server and watching how it's doing.
    For Win32::GUI apps, it comes out at around 3.5MB per copy on my system. Not trivial, but 30x3.5 is better than 30x6.9 :)
    Indeed ;o)
[reply]
      I don't think it does... AFAIK, the sessions on a Terminal Server are completely separate and don't really reuse anything.

      The following quote from an MS Terminal Services document clearly indicates that dlls are shared between sessions:

      Disallow Installing Multiple Versions of Applications with Shared DLLs

      Because many application versions share DLLs, only one version of an application can be run at a time. If multiple versions are installed on the system, it is very possible that different users will attempt to run various versions of the same application simultaneously. For example, both Microsoft Internet Explorer 3.x and Microsoft Internet Explorer 4.x share various DLLs that will fail to work properly when both versions are installed on the same server.

      Which means that the Executable, ReadOnly & WriteCopy (until they are written) parts of a perl app will be shared by all copies running in separate user sessions, so the impact of multiple copies will be confined to the Read/Write memory (stack/heap).

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        That sounds a lot more definite than the docs that I found... I think I'll just try sticking a script into a couple of sessions on a Terminal server and see what happens.
        Thanks!
[reply]

In Section Seekers of Perl Wisdom