How is memory used by a compiled VB application?

For example:

1) Is the entire program (Forms, Module, Classes, DLL;s loaded into memory
when the application is initially started? -- OR -

2) Is just the StartUp Form, Modules, and Classes loaded into memory and all
other dependent forms and DLL's loaded dynamically from disk when needed and
released when not (object = Nothing) ? --OR --

3) What happens?

Thanks

David

Show quote Hide quote Do you feel like going fishing?

http://msdn.microsoft.com/en-us/library/aa716224(VS.60).aspx

("Give a man a fish and...")
LFS

Thanks for link Mr. Serflaten.  Alway enjoy fishing.

Knew most of what's in reference:  Some of it appears to contradict the
article:
"Virtual Memory in Windows XP" by Alex Nichol
(.http://www.aumha.org/win5/a/xpvm.php)
Hence part of my confusion as how Windows is loading VB..


Specifically my  problem relates to:

------------ from MS ----------------

The space used by (nonstatic) local string and array variables is reclaimed
automatically when the procedure ends. However, global and module-level
string and array variables remain in existence for as long as your program
is running. If you are trying to keep your application as small as possible,
you should reclaim the space used by these variables as soon as you can. You
reclaim string space by assigning the zero-length string to it:
SomeStringVar = ""      ' Reclaim space.

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

I have several very long strings local strings in a Help menu option on a
StartUp Form.
Hence the Form is active thoughout the Apps usage.

My debate is should I move the strings to a separate Help Form
and load the help form when/if needed -- or -- keep them as strings
within the StartUp Form menu option.

Logic says the strings as is are OK as I believe (??) the compiler
stores the strings in a separate memory location with a pointer
reference in the StartUp form
and only beings in the strings
when the help menu option is invoked.
Hence -- like the form --  the strings would only be brought into memory
when the menu option is exercised.

Since the strings are local not private or global when the menu option
is exited they should be removed from memory and the pointer restored.

Or am I wrong?



Show quoteHide quote

Show quote Hide quote 4-5 paragraphs up from the text you quoted, there is this:

---
Data you place directly into your application at design time (as properties or as literal strings and numbers in your code)
increases the memory the application consumes at run time. You can reduce memory by loading the data from disk file or resources
at run time. This is particularly valuable for large bitmaps and strings.
---

If you are concerned of using too much memory for strings that are rarely
used, you might look into adding a resource file and only call them up as
needed (into local variables which get reclaimed on procedure exit...)

As the article you linked to indicates, Windows is managing memory
all the time, and may not remove data from memory when you think.
Even if you unload a form, there is no gaurentee that the form is removed
from memory, 'in case you need it again'.

So, unless you are talking megabytes of string data, I don't think I would be
so concerned.  Group your modules by function so that they are called only
when needed, and can be released, if memory gets tight....

LFS

This is really a two level question. How does VB handle loading things
in memory and how does a virtual memory operating system like Windows
handle things loaded into memory. Things that get loaded into memory but
are not being used will get paged out of memory by the OP.

Larry Serflaten wrote:
Show quoteHide quote

Mr. Serflaten, Mr. Weiss:

The above is the crux of the primary macro issue.
On a micro level you can write your code to try and optimize it as best you
can.  (e.g.  Optimize loops, use Len(string) for testing strings, etc. or
move lengthy strings to a resource file or other file.

On a macro level both VB and Windows are doing their thing.

So what if anything can you do to optimize VB so Windows uses it more
efficiently.  For example if Windows is controlling what is put in and out
of memory and when (forms, classes. modules, DLLs), then from what I can see
you can't do much.  Even grouping code in module -- a good practice -- seems
to be not of importance if windows decides it will retain the module even if
not needed.

I guess what I've really looking for is how the compiler optimizes things so
I can structure my code accordingly.  But even here, if the compiler in its
first pass moves things around (i.e. optimizes my code for its own use)
should I be worried about it and can I even do anything about it.

Info on this whole area seems to be VERY lacking.







Show quoteHide quote

David wrote:
....
I'm not sure what is in VB6 online documentation, but VB5 Books Online
has a section entitled "Designing for Performance and Compatibility"
that has subsections on optimization for size, speed tradeoffs and
discusses how/when forms are loaded/unloaded, etc.

The general principles outlined there are useful; much beyond those
generalities is basically (pun intended :) ) beyond the intended level
of involvement in details for VB--it was intended as a higher level
abstraction and such details considered unnecessary for the most part
for the programmer to worry about.

But, if you read the above sections you'll get a pretty good idea of how
VB works.

There is still an important difference between memory
holding 'active' code and memory which is marked by the
compiler (if it does so!) as removable, the last one can be
overwritten by Windows when another program requests
additional memory whereas the 'active' memory might be
swapped out in this case.

Larry,

Forgive me as you see this message tendious. It is not meant as this.

VB6 is created for computers when 500Kb was real hugh, how can it be
iteresting today as a computer with less then 1Gb memory is seen as small?

Cor

Show quoteHide quote

Yes it is. You're a liar!

Bollocks! When VB6 was created 128 MB was common. I had one such machine
myself. Your quoted figure of 500KB was common at least fifteen years before
that, even on my old Amiga as well as on PCs!

Machine code Assemblers were created for computers when 1K was real huge!
Are you saying there is no need for them today?

You're an idiot, Ligthert, and you are deliberately trying to damage the
Classic VB newsgroup in conjunction with McCarthy and one or two other dick
brains. You are a disgrace as an MVP and it is about time Micro$oft got rid
of you!

Michael

Visual Basic 6 was introduced in may 1998 in that time 128 mb was indeed
common
http://reviews.cnet.com/1710-5-0.html?sort=&year=1998,2002&node=3118&tag=mncol;select
for new systems .

When i started programming VB6 i got a computer with 256 mb internall memory
wich was later upgraded to 512 mb as also a that time it was common that a
progger had a highend system :-) .

The runtime limit of VB6  is not restricted to 2 gb as with VB.Net 32 bit it
is only restricted to the amount of RAM that is availlable

I guess that 500KB was more in line with GW-Basic
http://en.wikipedia.org/wiki/GW-BASIC cause my First Pentium computer with
windows 3.11 and Ms-dos 5.0 had already 64 mb of memory .

regards

Michel




Show quoteHide quote

There must be a typo here as I don't understand what it's saying Michel

No 32-bit application is restricted to the amount of RAM (physical memory).
That's what 'virtual memory' is all about. It's restricted by the
addressability of a 32-bit pointer, plus some organisational constraints -- 
the full potential of 4Gb is split into 2Gb of user (or rather 'process')
space and 2Gb of shared system space. Give or take some guard pages then it
means a 32-bit app is limited to about 2Gb of virtual memory. It doesn't
matter how much RAM is installed

Also, if the EXE has LARGEADDRESSAWARE flagged in its header then it can
address 3Gb of virtual memory. Also, if this same flagged EXE is run under a
64-bit O/S then it will have the full 4Gb of virtual memory addressable.
Again, this is all totally independent of the amount of RAM you have
installed.

    Tony Proctor

Show quoteHide quote

Tony


I stand corrected

I searched the web for the Max vals of VB6 but found only the phrase " The
runtime limit of VB6  is not restricted it is only restricted to the amount
of RAM that is availlable" wich is after rethinking and reading your
response obviously wrong .

Maybe it is because of my experience that i never have hit the limit with
VB6 but  have hit the limit with VB.Net that i wanted the above statement to
be
true  but fact is still that VB.Net and VB6 can both adress aprox 2 Gb of
memory on a 32 bit system .

Thank you for the correction and thorough explanation .

Michel Posseth



Show quoteHide quote

If you are using a terminal server, every 1MB seems huge. With 20+ user per
terminal server, this adds to something.

   Small? I'm running with 256 MB and it's plenty. I've
no trouble running the VB IDE, several copies of Notepad,
a few open folders, maybe a browser, a color picker, regedit,
MSDN, etc. There's no problem and no virtual memory use.
I just don't use Vista or .Net.

  The notion that 1-2GB of RAM is the minimum requirement
is a direct result of the extreme bloat in Vista (and to a lesser
extent the extreme bloat of .Net). In a flourish of poetic justice,
Microsoft's favor to their hardware partners -- trying to force
everyone to buy new PCs -- backfired. Now they're stuck with
a bloated mess in Vista that's too big for "netbooks".

   The attitude of many DotNet people seems to be similar.
If your software doesn't work well it's not your fault. It's the
end-user's fault for not buying a new PC with 2 GB RAM.
Why should you have to code efficiently. That's, like, so
not hot. :)

    Maybe the biggest problem is that people have been
sold on .Net as an all-purpose tool, when it's really designed
for server-side applets, like its cousin Java. Java was around
for years and nobody used it for Windows software. Then
Microsoft came out with their own Java clone and suddenly
it's well-suited for Windows software. What changed? Nothing!

   As an old-timer, how was it that you could buy into such a
silly salespitch as the idea that compiled software is "outdated"
and that JIT-compiled software based on a VM system of
multiple, superfluous, memory-hungry, wrappers is the wave
of the future. (It wouldn't be quite so absurd if MS at least
achieved cross-platform compatibility to justify the cost of
their VM. But current .Net is not even cross-platform among
Windows versions.)

Read it from a respected Windows expert:

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

A. I think you meant 512MB,  I was running VB3 on 8MB and that wasn't
     so huge....

B. Having 2 GB of available space does not mean the programmer should
     use memory foolishly.  It is still good practise to 'play nice' with the
     other apps the user might have loaded by taking steps to reduce any
     excessive memory usage.

In my opinion, that is what the OP wanted to do; he wanted to become
aware of methods to reduce memory usage.  I thought it was a reasonable
request.

LFS

500Mb for those who did not understand that I was meaning that


Show quoteHide quote

Show quote Hide quote Ha. That is an interesting question for a Saturday morning as it is a more
complex question that one might realize at first glance.

First off, within a system that used VMM (virtual memory management),
"memory" at any one time is likely to be stored (and loaded from) blocks and
pieces scattered hither and yon, and is not static - actual memory usage
will vary over time. Also a VMM uses optimizing algorithms to vary the
amount of memory available (or reported) depending on load - so what might
be true for an application on a developer's box, may be different when
observed on for a highly loaded busy server.

Second, consider that most objects (Forms, Controls, etc) and their
references have various 'parts' that may or not be loaded separately. eg.
every Function Directive will take 16+ bytes and is loaded upon start up. If
a subsequent call into the servicing dll require additional memory that
memory will be loaded into memory.

Normally this question refers to the amount of memory or average 'footprint'
reported by the Task Manager and other such tools.

Here is a general list: (And like all 'generalities' usually fails in the
specific.)
1) All .bas modules are loaded on start up
2) Forms and Classes are not loaded until they are called or created.
3) Classes declared with WithEvents will get an additional hidden object
reference (an extra 32+ bytes).
4) Memory for DLLs components will vary depending on what they request
during load, and how the VMM feels at the time.
(Dlls are all essentially loaded on startup - so they can be mapped into the
program's address space. How much remains behind or how much is reported
will vary.)
5) Setting something to Nothing doesn't necessarily destroy an object - it
merely decreases the reference count, marking it as availble for destruction
when the VB engine gets around to it, but in normal practice it acts very
deterministic. (automatic references vs. global references)

Others will be along to amplify and add to the list...

-ralph

Ralph:  Your response is the type of thing I'm looking for.
Any source that details this and the relationship between the two (VB and
Windows)

Show quoteHide quote

Following what Ralph has said David, I'd like to add my own twopennyworth.
It sounds a simple question, and is one that's regularly asked, but the
answer may be surprisingly deep and complex

OK, I think the scene has been said for Virtual Memory, and other posts have
highlighted that 'memory' isn't really 'memory'. The program executes in
'virtual memory' which is a combination of physical memory (RAM) and disk -
managed together by the Windows Memory Management.

Within the program itself, there are 3 main categories of (virtual-)memory
usage:-
* Stack
* Non-shared data
* Code and shared data

The local variables in a procedure call are allocated on the stack, and are
automatically reclaimed when the procedure call terminates. If any of those
variables contained an object reference then the body of the object would
not normally be on the stack. However, the object would be automatically
destroyed when the reference variable is reclaimed -- unless you've stored a
copy of the same object reference elsewhere. That would increment the
reference count on the object body and prevent it being destroyed until
later (when the reference count finally gets to 0)

Code (and some types of constant data declared in your source code) are
automatically shared on your system. This means that if you have more than
one copy of the EXE or DLL loaded on you system then they're using the same
copy of the code.

As you already know, any global variables in a *.bas module are allocated
when your program starts, and persist until it terminates.You can clear down
memory that they might reference (e.g. object bodies, string bodies, array
bodies) but you cannot remove the variables themselves because they're
global.

Almost everything else (e.g. object bodies, array bodies, etc) come from the
'heap'. This is an area of memory within your process that's gets carved up
to satisfy requests for such items. The heap manager takes care of
allocating bits of total heap, and returning unused bits back to the total
heap. However, the overall memory usage is obscured by the fact that the
heap has a coarse granularity. It maintains its own memory in chunks, or
zones, or whatever you want to call them. If there was a request for just
100 bytes and there was nothing free in the heap then it would have to
allocate a whole new chunk so that it could carve out 100 bytes for you. I
can't remember what the default chunk size is for Windows heaps but it's
big.

The complications don't stop there though. If you return that 100 bytes of
memory then that part of the heap's chunk is simply marked as free for
re-use - it doesn't get returned back to Windows in the VM sense. This often
confuses people into thinking that they have a memory leak because their VM
size (as shown by Task Manager) isn't decreasing. In reality, it's all that
extra heap management going on "beneath the water line". However (...I've
used that word a lot so far), if enough memory is returned to the heap then
the associated pages in that virtual memory are "decommited". This means
that the virtual addresses remain part of your process (..it cannot shrink
the total process size as the pages will be in the middle somewhere) but the
associated paging file resources are freed up, and may be used elsewhere on
the system. In fact, if those pages get re-used by the heap manager then
they are re-created as "demand zero" which is a very efficient way of
creating fresh zeroed virtual memory pages.

Monitoring memory usage is a bit like trying to count some unseen swimmers,
heading to your shoreline, based purely on the waves you see lapping at that
shoreline  :-)  They're probably contributing but there's so much else going
on that you can't work backwards from that data alone.

    Tony Proctor

Show quoteHide quote

Show quote Hide quote EXE's made with VB6 are loaded entirely at startup, not in parts.

EXE/DLL's generally can be segmented into parts called sections. In C++, you
have control over how the code and data are segmented. For instance, a C++
developer can make a DLL or OCX that manipulate graphics and splits the code
into two code sections, one for 2D, and the other for 3D graphics, so not
all the code is loaded at once. They do this through "#pragma" directives.

In VB6 we don't have this luxury. VB6 puts everything in 3 sections, one for
static data(Global variables), one for code(all the code for
modules/classes/forms, etc.), and the last section for resources. You can
verify that with programs that view the EXE header. I have tested this with
2 EXE's, one that doesn't have any forms, just one module with Sub Main(),
16 KB EXE size, and the other EXE has 30 forms, modules, classes, and one
user control, it's 1.2 MB in size. Both use 3 segments, so all the code is
loaded at once into memory at startup. Here is the software I used:

http://www.cgsoftlabs.ro/studpe.html

As for dynamic strings or arrays, I think VB6 uses
SysAllocString/SafeArrayCreate. VB6 and many other languages have their own
memory managers. The runtime pre-allocates some memory at startup and use
it, when more memory is needed, it just allocates "larger" blocks than what
you requested and use them. When you free memory, it just mark them as free
but may not return it to the system. It assumes that you are going to need
it again soon, so the memory is not actually returned to the OS. Some memory
managers actually free the memory when the application is minimized. I
noticed that VB6 does that on XP at least, not sure about other OS'es.

SysAllocString/SysFreeString is implemented in oleaut32.dll, which is part
of VB6 runtime and comes with some OS'es, so how strings are freed is
managed by that DLL or associated DLL's.

VB6 may be using heap functions in Windows for its own memory management as
explained above, but I am not sure. See HeapSize() and related functions.

While VB6 doesn't have "Free" statement for strings, other than assigning
empty strings, it does have Erase statement, but it's for arrays. Try
putting the long string in a resource using "VB 6 Resource Editor" Add-in,
and load it into a string var, or in array var of String, and use Erase
statement. I have not tested this, so I don't know if there is a difference.

The EXE is actually loaded on demand, via the paging system. At startup,
page table entries are created pointing to the corresponding areas of the
"backing file" (i.e. the EXE or DLL file). As the code executes, those pages
are automatically pulled into physical memory from the backing file.

If the same DLL is used in more than one program then this paging-in of the
code occurs in both processes. However, the backing file is the same and the
physical pages are the same. This then means less memory consumption, and
there's more chance of those pages being in physical memory because there's
twice the demand for them.

    Tony Proctor

Show quoteHide quote

Help with Binary Compatibility
Fonts
vb.net executing on
(OT) false positives on my files
Can I loop through only SELECTED items in a multi-select FileListBox?
Internal String Visibility
Should I distribute Winsock?
Visual Basic Express 2008 Custom Error Message
Dynamic function calls
moving controls around on a form