If Size matters, who compiles smaller, PB 8 or PB 9?

[Theo Gottwald]

This is our "Hello World Program" forTest 1.

Code Select Expand

#COMPILE EXE
#DIM ALL

FUNCTION PBMAIN () AS LONG
MSGBOX "Hello World"
END FUNCTION

               

First we try PB 8.04 and we get 5632 Bytes excutable.
FNV-Checksum is: 32 35 65 87 38
A second compile shows the exact equal result.

Now lets see PB 9. We expect a slightly grown Executable because of improvements in the Runtime.

We get 6144 Bytes in Size and a FNV-Checksum of: 25 93 32 32 65 the second compile shows another checksum as we already noticed, but has the same size of 6144.

Now we will include the WinAPI from Jose.
This time PB 8.04 has to stay out because its not able to compile the new headers.

We get a size of 12208 Bytes using the %USEMACROS=1 and
without defining %USEMACROS we get a size of 18432 Bytes.

Will say that using the MACROed Version, we just add 6064 Bytes to our EXE using the new include files.

We'll now switch to the supplied Win32API of each of the two Compilers.

Code Select Expand

#COMPILE EXE
#DIM ALL

%USEMACROS=0
#INCLUDE "Win32API.inc"
FUNCTION PBMAIN () AS LONG
MSGBOX "Hello World"
END FUNCTION



This time the PB 8 gives us the 6144 Bytes, Checksum: 36 96 20 54 74

PB 9 this time gives us 8704 Bytes. Please note that there may have been changes in the Win32API supplied with PB 9 and thats a possible reason fo this increase. We can see taht this is the smallest FIlesize to expect when using the supplied Win32API Files.

Let me say that at this place none of

#DEBUG ERROR OFF
#TOOLS OFF
#OPTIMIZE SIZE

does make any valuable difference.

Comment to the attachement:
I've attached my Checksum-Tool to this Post.
To install it, copy it somewhere and add a shortcut into the "SendTo" Folder.
To use it, just right click on any file and select in the PopUp Menu: SendTo "FNV-Display".

[Patrice Terrier]

if you want even smaller size then try PB7, PB6 

[James C. Fuller]

if you want even smaller size then try PB7, PB6 

Smaller yet pbdll 2.0 with Call32.dll

James

[Theo Gottwald]

... MASM and if I want Purebasic. I think Purebasic was even a few kb less ( 4 kb?). But i do not know the actual version even though i have a licence. Let's say if I'd really only had to bring up a Messagebox maybe I'd do it :-). And ... yes PB 3, 4 or 5. I think I started around PB 5 or 6 using PB.

[Patrice Terrier]

What about PBDK 

[Theo Gottwald]

PowerBASIC from Denmark ? :-)

[Charles Pegge]

Using the Oxygen Assembler, I can produce a Hello Message in 2.5k, A HelloWin with a proper Message loop and WndProc in 3.5K and and an Opengl viewer demo in 9 K (instead of 36k in PB / FB) The secret is to use fully relocatable code, and explicit DLL binding which minimises the section tables that an  Executable is required to carry. My test pieces currently contain a redundant export section so they are all bloated by 0.5K !

But there is little point in producing executables smaller than 4k, since that is about the smallest unit the OS filing system will handle, and Zipping programs squeezes out the air pockets very efficiently.

[Edwin Knoppert]

I noticed an increase of a few kb as well, ~ 3kb..

[Theo Gottwald]

Jose has modified his WinAPI for size.
See: http://www.jose.it-berater.org/smfforum/index.php?topic=2736.msg8201#msg8201

Actual results may therefore be quite different from what was written above.

[Steve Hutchesson]

this is an old topic but I have played with the problem myself. It would seem there is some dynamic code in win32api.inc for the two current versions that increases the size by about 2k even when you use %usemacros = 1 but if you include just the prototypes (DECLARE statements) you don't get the additional code added.

An empty pbmain function with PBwin90 builds at 5120 bytes so it does not appear to have ballooned out in size as 8.04 builds at exactly the same size. A bare window in MASM, POASM and JWASM will build at 1024 bytes with no icon and no .DATA section but add both and you tend to see them build at about 2.5k.

The size difference in PBwin90 is the dynamic string engine code and at about 2.5k its no big deal.

If there is a problem, it is in the layout of the include files which contains some dynamic code which is added whether you like it or nor. The macro equate solves most of the problem but it is still lousy design, an include file should add NOTHING in terms of dynamic code which should alwways be in a source code file, not an include.

[Theo Gottwald]

At time of this writing, I'd say "size doesn't matter".
While this topic is one of the most wanted topics of our forum.

Coming from Google, i doubt its about PB code-size that matters.
There must be another size that matters, if people google for "size matters" :-).