One of the core parts of QB64 is the parts system we use. Basically, QB64 converts BAS code into C code and then compiles it. That's a LOT of code to convert!!
Rather than try and reinvent the wheel from scratch, where possible, we plug in and link to existing C libraries to do stuff for us. We didn't write our own font, sound, image routines from scratch -- each one of those is a separate "part", or separate library, in QB64.
In an attempt to keep file sizes as low as possible, and to reduce memory requirements, we *only* link to, and include, the libraries as needed. This is what we refer to as our "Parts System".
Without *ANY* sound commands, we *never* link to, nor include, any of the sound library.
Test this:
1) Compile: PRINT "Hello World". View the EXE size.
2) Add a BEEP statement after that and compile. View the EXE size.
Since BEEP is a sound command, we link our sound library and the EXE size goes up several hundred kilobytes.
I honestly don't see any way that it could load *faster* by increasing the size larger and taking up more room in memory. The only way I can picture this making a difference in speeding things up, is itf the size just happened to pass some buffer threshold with the OS. Windows might not cache a 1MB file in a page file, but it might a 2MB file, passing some threshold of convenience.
If it loads faster for you, by some miraculous quirk of your system, by adding BEEP to the program, add BEEP to the program. Just don't expect that adding a whole additional library to the executable is going to run/load faster on other machines, or for other programs.
What you've found is most likely a singular quirk of your system, for this singular instance. I certainly wouldn't bank on it holding true anywhere else, or anytime again in the future.
