• 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.
  • Posts

    • George Benson and Hedges - Give me the Light!
    • it was a mobile OS first thats why its UI its so bad, the same with windows 8 which was more designed for tablets and again not as a desktop OS first.
    • "vista rebranded" lol w7 works, its not slow and sluggish we cant say the same thing about vista that run like crap even on new machines.
    • just get iot enterprise ltsc 2021 thats the w10 with support until 2032
    • Rufus 4.9.2256 by Razvan Serea Rufus is a small utility that helps format and create bootable USB flash drives, such as USB keys/pendrives, memory sticks, etc. Despite its small size, Rufus provides everything you need! Oh, and Rufus is fast. For instance it's about twice as fast as UNetbootin, Universal USB Installer or Windows 7 USB download tool, on the creation of a Windows 7 USB installation drive from an ISO (with honorable mention to WiNToBootic for managing to keep up). It is also marginally faster on the creation of Linux bootable USBs from ISOs. A non-exhaustive list of Rufus supported ISOs is available here. It can be especially useful for cases where: you need to create USB installation media from bootable ISOs (Windows, Linux, UEFI, etc.) you need to work on a system that doesn't have an OS installed you need to flash a BIOS or other firmware from DOS you want to run a low-level utility Rufus 4.8.2253 changelog: Switch to wimlib for all WIM image processing: Greatly speeds up image analysis when opening Windows ISOs Can speed up Windows To Go drive creation (But won't do miracles if you have a crap drive) Might help with Parallels limitations on Mac (But Rufus on Parallels is still unsupported) Enables the splitting of >4GB files with Alt-E (But still WAY SLOWER than using UEFI:NTFS) Others Switch to using Visual Studio binaries everywhere, due to MinGW DLL delay-loading limitations Add more exceptions for Linux ISOs that restrict themselves to DD mode (Nobara, openSUSE, ...) Improve reporting of UEFI bootloaders in the log, with info on the Secure Boot status Fix an issue with size limitations when writing an uncompressed VHD back to the same drive Fix a crash when opening the log with the 32-bit MinGW compiled version Fix commandline parameters not being forwarded to original Windows setup.exe Rufus 4.9.2256 fixes: Fix downloads from https://rufus.ie no longer working due to recent GitHub server changes Fix unofficial Windows ISOs, with single index WIMs, not presenting the WUE dialog Download: Rufus 4.9 | Portable | ~2.0 MB (Open Source) Download: Rufus 32-bit | ARM64 Links: Rufus Home Page | Project Page @GitHub | Screenshot Get alerted to all of our Software updates on Twitter at @NeowinSoftware
  • Recent Achievements

    • Explorer
      Legend20 went up a rank
      Explorer
    • One Month Later
      jezzzy earned a badge
      One Month Later
    • First Post
      CSpera earned a badge
      First Post
    • One Month Later
      MIR JOHNNY BLAZE earned a badge
      One Month Later
    • Apprentice
      Wireless wookie went up a rank
      Apprentice
  • Popular Contributors

    1. 1
      +primortal
      618
    2. 2
      ATLien_0
      277
    3. 3
      +FloatingFatMan
      178
    4. 4
      Michael Scrip
      150
    5. 5
      Steven P.
      115
  • Tell a friend

    Love Neowin? Tell a friend!