Sign in to follow this  
Followers 0
jftuga

Idea for reducing memory usage

9 posts in this topic

#1 ·  Posted (edited)

The Windows Server 2003 Resource Kit (which also runs on XP) has a command line program called empty.exe. You can download this program for free.

Here is the blurb from the help file:

Free Working Set Tool (Empty) is a command-line tool that frees the working set of a specified task or process, making those page frames available for other processes. A working set is a subset of virtual pages resident in physical memory.

If I run it on a compiled AutoIt .exe, it will drastically reduce the memory usage. After running empty.exe, memory usage drops down to 600-700k. Memory usage does grow, but it usually stays 40 - 50% less than when not using empty.exe.

It would be really awesome if this could be built into AutoIt itself by figuring out what API calls empty.exe uses and then incorporate it into the runtime - either completely automatically or by a function call. Is something like this doable?

-John

Edited by jftuga

Share this post


Link to post
Share on other sites



See SetProcessWorkingSetSize on MSDN. Its very easy to DllCall() it if it's that important to you. It should not be done automatically, however. Reducing the working set size will be a pretty significant penalty in initial speed as everything is loaded into memory, then immediately kicked out of memory, then the things that are currently needed are loaded back in with each new thing loaded back in as necessary.

Share this post


Link to post
Share on other sites

Thanks for the tip. To me, it is more of a perception thing than anything else. I would hate it if people didn't want to use AutoIt because they don't feel like a ~20 line script should take up 4-5 megs of memory. I was thinking how cool it would be if someone started up an AutoIt program and then opened up process manger and saw how little memory it used. From what I have noticed, the performance hit that you mentioned is negligible.

-John

Share this post


Link to post
Share on other sites

OK, I noticed EmptyWorkingSet() on MSDN:

The EmptyWorkingSet function removes as many pages as possible from the working set of the specified process.

http://msdn.microsoft.com/library/default....yworkingset.asp

How would I get the PID of the AutoIt process itself? And how could I use it in a DllCall? I have to apologize for not understanding how to translate a C function call to AutoIt's DllCall. An example would be great! :)

-John

Share this post


Link to post
Share on other sites

I think Run() returns a PID...


FootbaG

Share this post


Link to post
Share on other sites

#6 ·  Posted (edited)

processexist returns a PID if found.

atleast thats what i always use.

BOOL EmptyWorkingSet(

HANDLE hProcess

);

would be roughly by head

$i_return = DllCall($v_dll, 'int', 'EmptyWorkingSet', 'hwnd', $p_Process)
Edited by w0uter

My UDF's:;mem stuff_Mem;ftp stuff_FTP ( OLD );inet stuff_INetGetSource ( OLD )_INetGetImage _INetBrowse ( Collection )_EncodeUrl_NetStat_Google;random stuff_iPixelSearch_DiceRoll

Share this post


Link to post
Share on other sites

#7 ·  Posted (edited)

I think Run() returns a PID...

<{POST_SNAPBACK}>

layer, for about the 1392 time now, please don't reply if you don't have a clue. How useful will Run() be in getting the PID of the current process?

jftuga, GetCurrentProcessId() should return the PID you seek.

Edit: The Windows API function GetCurrentProcessId(), that is, not an AutoIt function.

Also, w0uter, although you could use "ProcessExist(@ScriptFullPath)" to get the PID, I don't know what sort of guarantee there will be that the PID will be for the correct instance if multiple instances of the same script are running. Using GetCurrentProcessId() would be much safer.

Edited by Valik

Share this post


Link to post
Share on other sites

layer, for about the 1392 time now, please don't reply if you don't have a clue.  How useful will Run() be in getting the PID of the current process?

<snip>

I know, but I was in a hurry and I knew there was that DllCall and processexists but I didn't wanna say "I am in a hurry and I will get back later with a better solution" in fear of my post being deleted for being off topic, sorry. :)


FootbaG

Share this post


Link to post
Share on other sites

I know, but I was in a hurry and I knew there was that DllCall and processexists but I didn't wanna say "I am in a hurry and I will get back later with a better solution" in fear of my post being deleted for being off topic, sorry. :)

<{POST_SNAPBACK}>

Then don't reply at all. No posts are far more useful than misleading posts. A lot of your posts are misleading because you generally don't know about the subject you are commenting on, and since the other poster doesn't either, they have no way of knowing that what you're saying is useless so they expend time chasing a wild goose.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0