http://www.javaop.com/~joe/WindowStuff.zip

In that zip, theres two EXE files that do the exact same thing: create a window. The source code to both is included (its Bloodshed Dev-C++ source code). I saw that in both source code and compiled form, the VB files are smaller. I find that rather interesting.

Uh, I'm not sure how Bloodshed Dev-C++ works, but is that .exe by any chance, a debug and not a release? :p

Also, note that VB uses mostly library functions, ocx stuff.  Whereas C++ may or may not be statically linked.  That would also inflate the size of the .exe.

Click here, noob.
Total executable size (in release folder): 3072 bytes.

Also if your compiler was optimizing for speed instead of size, that could be a factor ;\

What's the big deal about file sizes? It doesn't matter, as long as your application does what it's supposed to.

If all else fails, you can always use a file compressor like UPX to shrink its size for you.

Newby: Could have happened. I don't think so though.
iago: Er, hehe.
Rabbit: Another possibility, but *anything* should beat VB's optimizer =p. Even my JoeBASIC compiler beat it, heh.
Topaz: I was just saying, VB beat C++, which has always been held as better than VB at file size.

To all the people who said it doesn't, you're incorrect: the size of an .exe does matter. 

The bigger a program is, the longer it will take to initially load it into memory.  So if you have an exe that is very large, and you run it, it will take a lot longer to load because it has to be read from the harddrive into memory before it can be run.  Once it's there, if it's large, it might get swapped out to the harddrive (due to lack of memory) which will slow down the execution.  So smaller .exe's are good. 

For example, look at Firefox.  It's statically linked against all its libraries (to make sure that it's fully portable), and as a result it has a ~12mb memory footprint.  But it runs fast once it's loaded, if you have a decent amount of free memory, because of the first mitigating factor below:

There are, however, a couple of mitigating factors:
- A big exe that is statically linked won't have to load many dynamic libraries.  That means that it will load reasonably fast, since it doesn't have to load libraries, and won't take up as much memory as could be expected.
- If an exe is optimized for speed, then yes, it will initially take a little bit longer to load.  However, because the compiler does things like inline functions and unroll loops, you will get a significant speed increase while running.  This will almost certainly be enough to offset the extra loading time. 

So it's really a catch-22.  It makes a difference, for sure, but it's a trade-off. 

[quote author=iago link=topic=12619.msg125550#msg125550 date=1125063459]
To all the people who said it doesn't, you're incorrect: the size of an .exe does matter. 

The bigger a program is, the longer it will take to initially load it into memory.  So if you have an exe that is very large, and you run it, it will take a lot longer to load because it has to be read from the harddrive into memory before it can be run.  Once it's there, if it's large, it might get swapped out to the harddrive (due to lack of memory) which will slow down the execution.  So smaller .exe's are good. 

For example, look at Firefox.  It's statically linked against all its libraries (to make sure that it's fully portable), and as a result it has a ~12mb memory footprint.  But it runs fast once it's loaded, if you have a decent amount of free memory, because of the first mitigating factor below:

There are, however, a couple of mitigating factors:
- A big exe that is statically linked won't have to load many dynamic libraries.  That means that it will load reasonably fast, since it doesn't have to load libraries, and won't take up as much memory as could be expected.
- If an exe is optimized for speed, then yes, it will initially take a little bit longer to load.  However, because the compiler does things like inline functions and unroll loops, you will get a significant speed increase while running.  This will almost certainly be enough to offset the extra loading time. 

So it's really a catch-22.  It makes a difference, for sure, but it's a trade-off. 


[/quote]

Size does matter.  ;) What makes an impression on me with a program, is it's load time and memory usage.

[quote author=Krazed link=topic=12619.msg125587#msg125587 date=1125087296]
Size does matter. ;) What makes an impression on me with a program, is it's load time and memory usage.
[/quote]
but not its productivity, or useability?

[quote author=Joe[x86] link=topic=12619.msg125527#msg125527 date=1125055500]
Topaz: I was just saying, VB beat C++, which has always been held as better than VB at file size.
[/quote]

Did you read Myndfyre's post?

[quote author=Newby link=topic=12619.msg125594#msg125594 date=1125091716]
[quote author=Joe[x86] link=topic=12619.msg125527#msg125527 date=1125055500]
Topaz: I was just saying, VB beat C++, which has always been held as better than VB at file size.
[/quote]

Did you read Myndfyre's post?
[/quote]

I think the really important one to read is the one about static vs dynamic linking.