QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: zaadstra on February 23, 2021, 05:45:37 pm
-
Hi,
I accidentally stumbled upon a view with an old QB45 version and the recompiled QB64 program.
Then I thought: whoaaa what a difference! It it possible (with options) do do anything about this, or optimize it somewhere?
40 KB against 1449 KB, that's a lot!
[ This attachment cannot be displayed inline in 'Print Page' view ]
-
A possible answer...
With QB2.0, the program needed an external library (referred to in the current window path) to work (like BRUN20.LIB). The program could also be compiled in stand-alone mode with the BCOM20.lib library.
Sorry, I can't answer exactly for QB45, but the size difference could also be due to the need of an external library ???
-
My guess is that the size difference is due to the optimization of the code send to the QB45 compiler. I believe that it generated assembler language code based on the output MAP file that was generated. A small EXE was much needed back then.
QB64 is generating bigger EXEs as more features are added. I recall asking about this years ago and there was no interest in generating smaller files. You can the examine the code that is send to the C++ compiler. Compiler options won't shrink the EXE down to 40 kilobytes.
-
QBasic programs were 16bit binaries that used the console or graphic modes by interacting directly with the hardware.
QB64 relies on OpenGL for rendering. It's a full library designed to be the middle man between high level instructions and the operating system, and then the hardware.
Before QB64 used OpenGL, beta versions used SDL. Binaries were much smaller, but you had to ship several DLLs with your binary - they weren't stand-alone.
Besides the backbone of QB64 being OpenGL, all the functionality that QB64 emulates/recreates for use with modern systems is packed into two massive c++ files you can find in internal/c - qbx.cpp and libqb.cpp, not to mention that other libraries will be included automatically if you use external images, sound, tcp/ip, fonts, etc.
That's why our binaries are bigger - they're portable and contain whatever's needed to run, as opposed to relying on a runtime.
Last line is a personal remark: you don't need to worry about exe size in this day and age.
PS: Simple console-only applications will be smaller. Add $CONSOLE:ONLY to the top of your program if you don't rely on graphics et al.
-
40 KB can be faster, say on slow networks ;-) I think it is interesting not to follow lazy coders always filling available space on disk and memory. A good sport to code efficiently. I understand the libaries are always included. Also if you use none of the functions? GFX, audio, etc...
I code in 99% in screen 0, does that still use OpenGL? Just for commandline tools.
-
Start your programs with $CONSOLE:ONLY to get rid of most non-command-line stuff. If you're already testing v1.5, that's enough.
If you're in v1.4, add _DEST _CONSOLE after $CONSOLE:ONLY, to be able to use PRINT.
Audio, image, font - these are included as needed. But the internal for OPEN will be there even if your program never opens a file, and etc.
-
I compiled a small test program. The size is smaller (1.569 MB vs 2.035 MB), but the execution is slightly slower with $CONSOLE:ONLY.
-
Thanks, Felippe, I'll test. I gues I'm using OPEN in almost all programs, so that's no issue.
Interesting, wiggins. Worrying that it is slower. Are both your speed measurements consistent?
Note that my program (about 200 lines of code) is smaller, without $console.
-
If size matters more than speed go really, really small with an Interpreter, build one interpreter have millions and millions of code files potentially at a fraction of size of the .exe
But I think speed matters more, ah! to get there before you left! ;-))
-
Felippe, how can I make my QB64 binaries automatically compressed with UPX, after compiled? Where should I add such command?
-
Hello. I really don't know.
-
The thing to remember with QB64’s EXE size is that when you compile a BAS file, you basically compile it with EVERY command available— even the one’s you’re not using.
PRINT “HELLO WORLD”
That’s your whole one-line program. In c++, you’d probably write it as something simple like:
#include<iostream>
int main() {
std::cout << "Hello World\n";
}
Not much difference, except in c++ you specify which library your code needs to run. You ONLY need iostream, so you only include iostream, and thus you create a fairly small EXE.
But, BASIC was designed to take that hassle out of the way for beginner programmers. (You know, the B in BASIC...) Instead of making you keep track of a list of 3214 libraries and learn how to juggle them back and forth, learning when to add what and when to use what, BASIC basically makes them all available, all the time.
You don’t need to include a string library for RIGHT$, LEFT$, _TRIM$, MID$... You don’t need a math library for _ATAN2... No special graphics, sound, font libraries have to be manually juggled. You just type your code, compile it, and compile your one line of code with 300,000 lines of unused — but available — subs and functions floating in the background of the EXE.
About as small as a QB64 EXE is going to get is around 1.5MB. In today’s world, that’s a rather trivial size. When Galleon switched from SDL to GL as the backbone of QB64, he implemented a parts system where only required libraries would be compiled when needed — but those generally only apply to external libraries which we link to. Don’t use sound? Then we don’t add in the external sound library. Don’t use fonts? Then we don’t add in the external font library...
...But, at the end of the day, we still add in, more or less, the entirety of the BASIC library.
And that’s why your program EXE comes out to be the size which it is.
-
Hello. I really don't know.
Maybe this could be considered for a future release? An option like: "after compiling, automatically run this: <path> upx <generated EXE> <switches>"
-
Being BASIC doesn't have to mean that it is a dumb program - in fact I see QB64 as much more as the old BASICs.
Thinking of your library explanation, I would think of the precompiler looking which commands are used, and add the proper libraries. The biggy bulk library could be split in some parts with commands in the same group.
Or, a metacommand that states an advanced user will define which libraries must be included (but automatic is always better!). Omitting that includes all ... Just thinking a bit ;-)
To FilipeEstima, I would solve your wish by creating a small batch file, with the QB64 commandline compiler command, and then a line with the UPX compressor. Add the %1 variable to make it flexible.
Thinking of UPX, the first thought is that virusscanners get nervous about those UPX compressed programs ...
-
You can try changing the contents of makeline_win.txt in internal\c\. It's not a drastic change but it does make the exe size smaller.
Change the line in the file to this:
c_compiler\bin\g++ -s -Wfatal-errors -w -Wall qbx.cpp -lws2_32 -lwinspool parts\core\os\win\src.a -lopengl32 -lglu32 -lwinmm -lgdi32 -mwindows -static-libgcc -static-libstdc++ -D GLEW_STATIC -D FREEGLUT_STATIC -lksguid -lole32 -lwinmm -ldxguid -Os -Wl,--gc-sections -o ..\..\
-
You don't want to use upx for a program that isn't console only. If you do, it has to unpack the program first and then run. This slows it down immensely. With a console only program, it's just as fast and is tiny. With a program that uses the regular screen in QB64, slow as a turtle. Be careful what you wish for. Then again, I could be wrong. Something else I just compressed worked just fine. I don't know.
-
I made a custom QB64 IDE build by adding a line that takes the compiled exe and uses the most aggressive compression flag. I was able to actually turn the 7 meg QB64 x64 exe to just over 2 megs.
-
And I clicked the ADD DEBUG INFORMATION when compiling QB64.bas and ran out of drive space making the EXE... ;D