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 :)

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)

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.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Perl is not that economical on memory (then again as you will see it ain't half bad either). A simple hello world script uses 1.8 MB. If you use Win32::Console your hello world script will need 4 MB. So in summary you need a minimum of circa 2 MB to do anything with perl and 4 MB if you do it in a Win32::Console window which will give you circa 1980s graphics. If you need it small perl is not the best tool.

You could do LWP type stuff with alert windows with a little HTML/Javascript but that will be 22 MB for the IE instance.

If you try to use vbscript you will find that wscript.exe uses 5 MB.

If you try to use a batch file you will find that cmd.exe also uses 5 MB.

I think if you are stuck with using C/C++ or assembler to make a native exe if you need lots of instances that don't use much memory. The problem with all the simpler ways to do it are that they provide all sorts of functionality you don't need, and as a result burn a lot more memory that absolutely required.

That's what I feared... out of curiosity, I installed the latest MS Visual C++ IDE, clicked together a simple app and ran it... It consumed even more memory than all the other things I've tried.

While the numbers are even less comparable (because of all the .Net abstraction), I'm stuck there as well. Writing it all myself in rather low-level C was something I tried to avoid ;o)

As BrowserUk points out things are not as bad as they seem with Win32::GUI as it is a wrapper over inevitably loaded DLLs. If you read the terminal services blurb here it notes that some resources are cloned and some shared. I think it is highly likely that perl.exe/perl.dll will get cloned so you are up for 2MB there as a minimum. This is not that bad when you compare it to other options.

However I don't think the problem is as big as you believe as a process that does something, then sleeps for a while is likely to get paged to disk so if you had 50 4-8 MB processes running asyncronously in different sessions the actual RAM hit at any given time will not be that bad (far less than a pure multiple). The less often the widget widgets the less the issue.

Rather than just rely on Windows and paging to deal with it one option would be to get the widget to explicitly schedule itself with at.exe so it runs, updates at.exe to fire it up again in x minutes and then explicitly exits.

Another option might be to run a single process on the terminal server that groks a list of user sessions, checks whatever remote file you are supposed to check per user and then issue cute little pop up window warnings on the remote machines via NET SEND

NET SEND {name | * | /DOMAIN[:name] | /USERS} message

NET SEND Administrator Just another perl hacker!
[download]

Unless you actually need to download the file to the users session that should do what you want and avoids the multiple instance problem fullstop.

If you only need to notify them then Win32::MsgBox( 'Hello World') might be enough.

But for Win32::MessageBox I need to load the Win32 module... And when I'm doing that, I can use the rest of the module as well without really changing how much memory the script uses.

Do not confuse Win32.pm with Win32::GUI! If I try a tiny script like this:

use Win32;
#use Win32::GUI;
Win32::MsgBox("Hello world");
[download]

then without the Win32::GUI Task Manager reports 2332KB and with 3832KB.

Jenda


Support Denmark! Defend the free world!