How to start program Minimized as to show less memory usage in Task Manager?

[Eric Pearson]

> the "appearance" of minimal memory consumption

You could also phrase that "a truer indication of memory consumption".

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Lance Edmonds]

Well that suggests a couple of things to try.

1. The apps you mentioned may also use a hidden window, so you may need to actually assign some caption text to the dialog window to distinguish your hidden window from other windows.

2. Your app is not providing a message pump, so although you have created a Window, there is nothing to occuring to actually service the message queue.

Why not try starting this dialog as a separate thread and explicitly starting the dialog as a modal dialog... that way the message queue will be serviced, so when another app tries to send a message like %WM_GETTEXT, the message is processed.

Alternatively, recreate your app to work "inside" the callback for the hidden window... triggered either as a %WM_USER message, or as a separate thread.

This will obviously add a bit to the overall memory consumption, but it may still give you the results you are looking for (the "appearance" of minimal memory consumption).

My $0.02...


------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Wayne Diamond]

I was using these three lines, and they were doing the trick perfectly... until I tried to start Photoshop and/or mirc!
The instant i kill my process, photoshop/mirc will spring back to life

Dialog New 0, "", , , 0, 0, %WS_SYSMENU + %WS_MINIMIZEBOX To hDlg
Dialog Show State hDlg, %SW_MINIMIZE
Dialog Show State hDlg, %SW_HIDE

Comment those three lines out, recompile it, and it runs fine and Photoshop/mirc also load fine... (except Task Manager now shows 1200kb+ memory usage instead of 5-700kb)

--

Using Visual Studio 6's process viewer, my program (without the 3 Dialog lines) showed:
Working Set: 1060kb
Heap Usage: 180kb
With the 3 window lines in...
Working Set: 528kb
Heap Usage: 180kb

Compared to Notepad.exe ... in normal state:
Working Set: 1372kb
Heap Usage: 152kb
Minimised:
Working Set: 92kb
Heap Usage: 152kb

am i feeling slightly envious? well, yes...


------------------

[Wayne Diamond]

Steve, thanks very much for taking the time to write that, I always learn something from what you publish here. As an assembly guru you're looking at the program source and seeing code that basically shouldn't be there, and I hear ya big fella! But hardly any of my customers would care if there was an invisible dialog window that they didnt even know about, especially when it has virtually no impact on the running of the program - I'm only trying to look at this from the perspective of a would-be customer who decides to see how much memory my program is using by using good old Task Manager ... sure it's a coverup, and it seems that we have to create a window just to do that coverup, its crazy! But my customers will probably actually be happier?
But, my program is a UDP Server/invisible daemon kind of thing for LANs. It needs to have an invisible window anyway so that it can receive messages, so in this particular case, im not actually creating an extra window to do the mem-usage-coverup, im just using that same window...
anyway while im here id like to thank everyone for their time in testing this, seems there are new questions to be answered though
Cheers!


------------------

[Steve Hutchesson]

Guys,

The way I tested the "Stack Reserve","Stack Commit" parameters some years
ago was to run many instances of a test program to see if effected the
total memory usage in a linear manner, it didn't.

Next test was to run a large number of different programs to see if the
memory usage was linear, it wasn't.

The Portable Executable standard is the same across the range of 32 bit
Microsoft operating systems from win95 up and NT4/Win2k so the same things
apply.

As a side hobby I write small memory footprint editors and the single
factor relevant is the amount of code in the application and the amount of
memory that they allocate on the fly. Effectively the stack parameters do
not matter.

The things that you would normally look at in memory usage terms are code
size, memory allocation and deallocation and make sure that you don't have
any memory leaks with GDI and similar functions. Track transient memory
usage to ensure that you don't have overlapping allocations that are not
needed and deallocate when the memory is no longer needed, not at the end
of the proc.

I understand what both Eric and Semen are after with the NT specific APIs
but I see them as extra code and processor time for no purpose. The binary
generated by the PowerBASIC compilers is very efficient if the code is
written properly and that is simply more efficient than covering up a
trivial reading.

Regards,

[email protected]

------------------

[Semen Matusovski]

Guys --
look

   #Compile Exe
   #Include "win32api.inc"
   
   Function PbMain () As Long
      Local hDlg As Long
      Dialog New 0, "Test", , , 100, 100, %WS_SYSMENU Or %WS_MINIMIZEBOX To hDlg
      Dialog Show State hDlg, %SW_MINIMIZE
      Dialog Show State hDlg, %SW_RESTORE
      Dialog Show Modal hDlg
   End Function

Win200: 280 K. If dialog is invisible - 156 K (w/o %SW_RESTORE)


------------------
E-MAIL: [email protected]

[This message has been edited by Semen Matusovski (edited November 10, 2000).]

[Eric Pearson]

Semen --

Does your technique work on Windows 98 systems? I have been using the 98 System Monitor to check, and I'm not seeing any effect.

Wayne --

> Is [the API technique] more beneficial than Semen's example?

No, my initial testing indicates that Semen's technique appears to give slightly better results. I'm a little concerned about "using up" the first-created window because it has other special properties that I need in my program -- I need to make it visible -- but I'm going to investigate this technique further...

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited November 10, 2000).]

[Eric Pearson]

> I did mean Semen's code!

My apologies to both you and Semen... When you said "three lines of code and a declaration" I thought you meant my code, because Semen's appeared to be much longer. I see now that the "solution" part of Semen's code is that brief.

> would you be kind enough as to make
> a little hello world example for me?

Sure, I'll put something together and post it later today. But it will have no effect on Windows 9x systems, since the API is only supported by NT/2000.

> which works on my mothers Win98 box

Semen's technique is providing good results on my NT machine too.

> I dont have any programs to measure the
> memory usage at the moment

Have you tried Start / Programs / Accessories / System Tools / System Monitor?

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Wayne Diamond]

Eric, I did mean Semen's code!
I haven't tried your code yet as it isn't for Win9x, however you may be onto something with that API call - would you be kind enough as to make a little hello world example for me?
Is it more beneficial than Semen's example? (which works on my mothers Win98 box, although I dont have any programs to measure the memory usage at the moment)




------------------

[Peter Manders]

You have to remember that EXE's are only mapped to linear address space when loaded.
Parts are swapped into physical memory whenever they're accessed.

I think this playes a major role in what y'all are seeing.


Peter.


------------------

[Semen Matusovski]

Originally posted by Eric Pearson:
I think you meant my code

Eric --
I'm doubt that Wayne made a mistake.
At least, under Win2000 there is an effect, which is not possible to explan.

Wayne -
I'm lazy to reboot - did you test under 9x ?
(not sure that such effect exists here)

------------------
E-MAIL: [email protected]

[Eric Pearson]

Wayne --

> Semen, your code did the trick fantastically

I think you meant my code, but in any case...

More info... When you perform the SetProcessWorkingSetSize operation periodically, you will probably see even further reductions. My program calls my SetProcessWorkingSetSize function just before it enters its main message loop, and again every 10 minutes on a timer (but only if the program has been idle). I see an initial reduction from around 1500k to around 6-800, then down to around 350. But if I call the function twice in a row just before entering the message loop, there is no additional gain. I have no explanation for that.

So calling it every so often appears to help. On the other hand, calling the function too often will probably result in a lot of "memory thrashing" and a performance penalty.

Chris --

I'm not sure I understand your question.

> The memory usage reported, is it affected by
> the OS DLLs loaded by the app.

Processes use memory, not modules. But sure, if your application uses a DLL (system or otherwise) that uses a lot of memory, I would expect the NT task manager to show that usage. But DLLs don't have stacks, and I believe they get their string memory from the same pool that is allocated to the process (the EXE), so I would not expect the use of a DLL to increase the "reserved" memory that a program has, just the "used" memory, if any.

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Chris Boss]

I would like to add a question this this thread:

What relation to the memory usage discussed does the
operating system DLLs loaded for an app play in this ?

Depending on whichever API calls are used, different OS DLLs get
loaded by an app. The memory usage reported, is it affected by
the OS DLLs loaded by the app.


------------------

[Wayne Diamond]

wow! many thanks to all for the feedback, and we have a winner!
Semen, your code did the trick fantastically (just three lines and a declaration), my app now runs just as normal, but Task Manager now shows approx 500kb instead of 1000kb!
Obviously it has no huge impact on the program, but as Eric pointed out potential customers and even software reviewers often glance at such things, and whether Task Manager is gospel or not, it's shipped with NT and i think many people use it? i do
Anyway, im happy with that solution, it's doing the trick nicely
Many thanks again




------------------

[Semen Matusovski]

I don't seriously beleive in "Stack" parameter.
At least under Win2000 I see direct link between state of first (note, first) top-level window and "memory usage".
[code]
#Compile Exe
#Register None
#Dim All
#Include "Win32Api.Inc"

Function PbMain () As Long
Local hDlg1 As Long, hDlg2 As Long
Dialog New 0, "Nothing", , , 100, 100,, %WS_EX_TOOLWINDOW To hDlg1
Dialog Show State hDlg1, %SW_MINIMIZE
Dialog New 0, "Test", , , 100, 100, %WS_SYSMENU Or %WS_CAPTION To hDlg2
' Control Add Button, hDlg2, 101, "Click me", 10, 10, 80, 15
' Control Add TextBox, hDlg2, 102, "", 10, 30, 80, 60
Dialog Show Modal hDlg2
End Function
[code]

For this code I see 384 K.
If do not create additional window - 180 K.
If to uncomment Control Add, memory usage increases.
If to begin to type - again increases.
If to begin to include API calls - memory increases again.

Note, that smss and similar programs have no windows.

For myself I understood that this question has no direct relation to PB compilation.
With "features" of OS - yes.





------------------
E-MAIL: [email protected]

[Eric Pearson]

Steve --

> I would not lose any sleep over these memory figures

I agree, but sometimes you come up against a potential customer -- usually a non-programmer -- who thinks they're an expert and beats you up about things like that. If there are "harmless" things I can do to avoid an issue, I usually do them.

-- Eric

------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[Steve Hutchesson]

Wayne,

I would not lose any sleep over these memory figures, it corresponds
to two settings in the PE file header, "Stack Reserve" and "Stack Commit"
being you minimum and maximum stack usage. Default in a PowerBASIC EXE
is 1 meg which is more than enough in most instances. LOCAL memory in
a function or sub uses the stack and the demand varies with the stack
usage.

If you need more memory than is available on the stack, you are better off
to dynamically allocate it with GlobalAlloc(), VirtualAlloc() or one of the
OLE memory allocation functions. Usually stack faults come from message
deadlocks and other similar mistakes rahter than the stack limit size so
if you code is written properly, you should not have any problems.

Regards,

[email protected]

------------------

[Eric Pearson]

As I understand it...

The "Mem Usage" column of the Windows NT Task Manager displays (basically) "how much memory is available to your program -- reserved for its use -- right now." Windows will give it more memory if it needs it, or take memory away from that total, as the demands of the system require. If your program is using memory and another program (or the OS itself) needs it, the memory will be swapped to disk. If your program is not using memory when another program needs more, your program's total will simply be reduced. But again, if your program needs more memory it will get it.

The memory that is used by a program is affected by the size of the stack that is allocated to it (as Lance described), the amount of memory that Windows has allocated for strings, and the number of windows that it owns, among other things.

When the user minimizes an application, Windows assumes that the app is becoming inactive (and therefore does not require as much memory as it did) so it re-analyzes everything and "aggressively" trims the memory usage.

You can affect the number that is displayed by using this code in your program...

DIM hProcess AS LOCAL DWORD
hProcess = OpenProcess(%PROCESS_ALL_ACCESS,0,GetCurrentProcessId)
SetProcessWorkingSetSize hProcess,BYVAL -1,BYVAL -1
CloseHandle hProcess

(Depending on how the parameters of SetProcessWorkingSetSize are DECLAREd (as LONGs or DWORDs)you may need to use %MAXDWORD instead of -1.)

WARNING: I have not measured how setting SetProcessWorkingSetSize affects an application's actual performance, and I would welcome input from others about this issue. If I understand what I've read, it should not have any effect unless your program attempts to use a large amount of memory after making the call to SetProcessWorkingSetSize, in which case it would take a small amount of time for Windows to allocate a new block of memory.

Also, only Windows NT and 2000 support SetProcessWorkingSetSize, so you should test the Windows version and only execute that block of code if 95/98/ME is not detected.

It does make a difference where in your program you place that code. If I put it at the very beginning of WinMain it has no effect. If I place it just before my program enters its message loop (i.e. after the program has used a lot of strings during init, and after all of the windows have been created) it seems to cut the displayed memory usage significantly. Some of the reading that I have done says that you should execute that code periodically, like once an hour or whenever the program goes into an "idle" or "wait for user input" mode.

But again, the effect (as I understand it) is more or less "cosmetic" because Windows will give your app more memory if it needs it.

The SetProcessWorkingSetSize function does not reduce the displayed Mem Usage nearly as far as minimizing the app does. Apparently Windows reserves its most "aggressive" memory management for apps that have been minimized by the user.

-- Eric


------------------
Perfect Sync: Perfect Sync Development Tools
Email: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited November 10, 2000).]

Add virtual memory to what task manager is presenting. When minimized,
NT goes into hyper VM mode. Task manager's memory usage is probably meant to be a guide and not the gospel.

------------------
Ron

[Wayne Diamond]

The relevance is that if somebody is reviewing my program, I want them to see the memory usage as being the least my program has to use... PB is obviously doing a very good job of it, as minimizing a PB window proves that... but thats only if the user physically minimises it themselves - id just love to know how to initialise my program so that it is running in that minimised, least-memory-used state
As my program is a background hidden task kind of program, I should be able to run it in a 'minimised' state -
Other NT programs that already run with minimal memory:
smss.exe - 20k
winlogon.exe - 136k
notepad.exe - 96k
spoolss.exe - 344k
pstores.exe - 516k
nddeagnt.exe - 40k

So it seems there is definately a way to do this, otherwise smss.exe would surely read at around 1020kb...


------------------