• 0

Why does VB apps use so much memory?


Question

16 answers to this question

Recommended Posts

  • 0

The answer to query lies in the fact that VB6 is an interpreted language whereas what you're expecing is a compiled language. (If you need to know the difference, then Google it).

VB6 is generally regarded as a memory hog compared to solutions for same problems when comapred to C or C++ programs.

Parimal

  • 0

I write all my software using VB6, and it's most likely that it's because the VB6 runtimes are attached to each program you write. This is why there's an extra 3MB or so to your app. But like hash said, memory is cheap these days, and who cares if it's 3mb or 500kb.

  • 0
  parimal_kumar said:
The answer to query lies in the fact that VB6 is an interpreted language whereas what you're expecing is a compiled language. (If you need to know the difference, then Google it).

VB6 is generally regarded as a memory hog compared to solutions for same problems when comapred to C or C++ programs.

Parimal

I thought that VB6 was a compiled language. :huh: :unsure:

  • 0

Change the compiler mode... "P-Code" and "Native Code", I don't remember which one is default, try both.

Programs programmed in assembly language uses the smallest amount of memory, Windows allocates memory for the program and if the program needs more then the program must call external functions that the assembler doesn't put there itself.

  • 0
  parimal_kumar said:
Nope! VB 6 is most definitely interpreted. That's why it's deemed slower than its compiled counterparts such as VC++

Parimal

Wrong. VB 6 defaults to compiling to a native binary. You have to go in and change the setting to get PCode. It's been that way since VB 5.

  • 0

It still heavily depends on several system libraries, such as MSVBVM*0.DLL or something like that.

You can see the list of exports that DLL provides, and it doesn't matter wich way you compiled your program (p-code or native), it still requires many many many functions from it.

  • 0

Yes, vb6 is compiled. No, the runtimes are not included in the exe. The reason for high memory usage is similar to why .net uses so much; if your system begins to run out of ram, less is allocated to the vb6 app. If it really bothers you, use the SetProcessWorkingSetSize API and lower the mem usage that way.

  • 0
  Latka said:
It still heavily depends on several system libraries, such as MSVBVM*0.DLL or something like that.

You can see the list of exports that DLL provides, and it doesn't matter wich way you compiled your program (p-code or native), it still requires many many many functions from it.

VC++ has its own libraries as well, such as msvcrt.dll.. so comparing required runtimes to memory usage doesnt really work

  • 0
  hash said:
VC++ has its own libraries as well, such as msvcrt.dll.. so comparing required runtimes to memory usage doesnt really work

Well no, you can't "compare" the memory requirement to the runtime, because the VC runtime libraries don't do the same things that the VB runtimes do; they're really not even the same thing. The VC runtimes are Win32 DLLs that a VC++ application calls to get work done; the VB runtimes are COM libraries.

That's actually the source of the extra memory requirement (to answer the original question). VB programs aren't actually programs by themselves; they rely on COM.

  • 0

ok....heres the DEFINITIVE answer to ur question:

like everyone else so far has told you, yes VB6 DOES require certain runtime files. These runtime files are loaded in the memory even before YOUR app starts, and even before your first line of code is executed, or your first form pops up. When you goto the VB6 package and deployment wizard it includeds these runtime files in your distribution, so that when you give your program to your friends, who might not have these runtime files, it will install them on their PC.

is this really bad? well, yes and no. from a purely technical standpoint, this tells you that yeh, VB6 is inefficient compared to other languages like C++ or C. It imposes a significant overhead (roughly 2-3 MB), which might make your small apps, and nifty tools that you program in VB seem quite ugly, compared to what they could have been if made in VC++.

However from a more realistic viewpoint, it hardly matters. Firstly because like everyone said, 2-3 MB in todays world is hardly a problem. With systems having 512+ MB, im sure everyone can spare a little extra. Secondly, this overhead of 2-3 MB remains constant no matter how large YOUR application is. So wheather you make a 1 form app, or a MONSTER containing 200 forms, and a couple of thousand lines of code, the EXTRA amount taken will remain 2-3 MB for the dll files, and you will notice that the memory occupied doesn't increase so sharply as the size of your app grows.

Hope this helps

danish

This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.