in reply to Re: Memory requirements for a Win32 GUI
in thread Memory requirements for a Win32 GUI

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)
  • Comment on Re^2: Memory requirements for a Win32 GUI

Replies are listed 'Best First'.
Re^3: Memory requirements for a Win32 GUI
by BrowserUk (Patriarch) on Apr 14, 2008 at 13:58 UTC
    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.
      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!