in reply to Memory requirements for a Win32 GUI

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.

  • Comment on Re: Memory requirements for a Win32 GUI

Replies are listed 'Best First'.
Re^2: Memory requirements for a Win32 GUI
by pvbcharon (Beadle) on Apr 14, 2008 at 12:51 UTC
    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)
[reply]

      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.

[reply]
[d/l]
        Yeah, I thought about moving stuff to a central instance and only querying that instance - which would still leave the GUI burden on the particular instances.
        Sending messages to users via NET SEND is an interesting idea... I'll see whether that's enough or whether I need to customize the message beyond NET SEND's abilities.
        Thanks for the pointer to the Microsoft docs. Everything I had found was a little vague...
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom