Prev: Win7 and UAC with VB6 apps
Next: New problem installing VB6 on Win7 64 bit
From: FM on 10 Dec 2009 20:34
Trying to finalize and minimize the size of a VB project here and prefer
control arrays loaded at form load over independent controls. Never thought
about it before but in task manager the arrayed controls actually use more
memory than independent controls. Its not a lot just a 100kb or so but is
that to be expected? Is task manager a reliable source for quick memory
usage testing?

Another thing wondered, can someone tell me why is that when a compiled
*.exe (it seems to be the same for any app not just compiled vb projects) is
minimized and then restored, why is it the memory usage is a lot less than
before it was minimized or when the app was loaded. I would have guessed it
would be the same as before minimization took place.

Regards

FM


From: Dee Earley on 11 Dec 2009 04:22
On 11/12/2009 01:34, FM wrote:
> Trying to finalize and minimize the size of a VB project here and prefer
> control arrays loaded at form load over independent controls. Never thought
> about it before but in task manager the arrayed controls actually use more
> memory than independent controls. Its not a lot just a 100kb or so but is
> that to be expected?

I've never seen that before.
It seems a bit silly though and more work is needed on your part
(Possibly used to it from C/C++? :)

> Is task manager a reliable source for quick memory usage testing?

You can see rough trends.
I use a small program that logs process memory values using
GetProcessMemoryInfo() and excel to graph them.

> Another thing wondered, can someone tell me why is that when a compiled
> *.exe (it seems to be the same for any app not just compiled vb projects) is
> minimized and then restored, why is it the memory usage is a lot less than
> before it was minimized or when the app was loaded. I would have guessed it
> would be the same as before minimization took place.

Some memory blocks are cached and reused, and may be released at any time.
When minimising is a good point as it may not be used for a while.

--
Dee Earley (dee.earley(a)icode.co.uk)
i-Catcher Development Team

iCode Systems
From: Nobody on 11 Dec 2009 05:58
"FM" <spam(a)uce.gov> wrote in message
news:ebUqkIgeKHA.5136(a)TK2MSFTNGP02.phx.gbl...
> Trying to finalize and minimize the size of a VB project here and prefer
> control arrays loaded at form load over independent controls. Never
> thought about it before but in task manager the arrayed controls actually
> use more memory than independent controls. Its not a lot just a 100kb or
> so but is that to be expected? Is task manager a reliable source for
> quick memory usage testing?

You are probably doing something else that consumes more memory. Try testing
in a new project and see if there is any difference to be sure.

> Another thing wondered, can someone tell me why is that when a compiled
> *.exe (it seems to be the same for any app not just compiled vb projects)
> is minimized and then restored, why is it the memory usage is a lot less
> than before it was minimized or when the app was loaded. I would have
> guessed it would be the same as before minimization took place.

Because VB Runtime memory manager uses that time or message(WM_SHOWWINDOW)
to actually free unused memory blocks. Initially it allocates some memory
ahead of time from the OS, then when you ask for memory(when you assign
something to a String variable or use ReDim), the memory manager uses the
already allocated memory. If there is not enough space, it asks the OS for
more, usually more than you requested in anticipation for future use. When
you are done with the memory, the memory manager does not release the memory
immediately to the OS(except perhaps for large blocks), but just marks the
block as unused and release it later back to the OS, or keep it in
anticipation of feature use. However, it does return the memory to the OS
occasionally. The logic it uses is undocumented and can change with service
packs. For example, it MIGHT be that if you are freeing 1 MB+, it's returned
to the OS immediately, if it's less then it's just marked as free(or as some
call it returned to the memory pool, or back to the heap). Again, the logic
used is undocumented, but you can try ReDim SomeArray(n) As Byte to see how
this affects memory usage. Use "Erase SomeArray" to free the memory.

Not returning the memory to the OS immediately is done for performance
reasons. It takes time for the memory manager to free and restructure its
data, so it's done at times when the runtime designers saw to be the best
time to do this, such as when minimizing the application.

The above is true for most languages, not just VB.

In one application that I made, it runs in the system tray and Form1 is
hidden all the time. Form1 has only one button and one label(for debugging).
There are other hidden forms. I found that the memory usage is 12 MB when
the form is not minimized, and 4.5 MB when minimized. In both cases the form
was hidden. This line made all the difference in Form_Load and the form was
only loaded once:

Me.WindowState = vbMinimized

Finally, use Process Explorer because it shows more details. In particular,
"Private Bytes". This is not shared when the user starts multiple copies of
the same application. The code however is the same and Windows doesn't need
to allocate double the memory for the same code. This may not be a big deal,
but in a Terminal Server, some run 30+ sessions simultaneously(30+ users or
30+ copies of your app), so 10 MB per process becomes 300 MB. This would
slow down the server, and consequently your application.

The article below shows how to interpret the numbers and screenshots:

http://blogs.technet.com/markrussinovich/archive/2005/04/16/the-coming-net-world-i-m-scared.aspx

Process Explorer
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx


 | 
Pages: 1
Prev: Win7 and UAC with VB6 apps
Next: New problem installing VB6 on Win7 64 bit