PureBasic v6.10 is producing a file size 5 times bigger than v6.04

[plouf]

Loosing the point a lot of guys !!

Its NOT 5 times larger, its the smallest possible size now 150kb
I.e. a program that was compuled at 5mb now will get 5,15 mb !! It willNOT GET 5*5= 25MB

Its complete lost of energy to add a option for old clib linking
With maintenace of old and new libs... !!
If you just need so much to have a smaller size (install it on a 5,25 disk?!) Download older pb !
Since this PC with such limitations would me an old pc anyway with winXP or even win98 so ...

[Fred]

Indeed it's not 5 times larger, but for small programs it looks like it, as you said it's the minimum size of the program which changed. It was 150 kb using link.exe from VisualStudio but with polink.exe it's more like 450kb. Nothing to hide here and it's perfectly reasonable by nowadays standards considering there is still ZERO external DLL dependencies for created exe (which is the most important point IMHO).

[Caronte3D]

+1000000

[AZJIO]

I am currently breaking these big include library files down into many small pbi files, only included when needed

"C Backend" checks for unused functions and never adds them to the compiled file.

[plouf]

Indeed it's not 5 times larger, but for small programs it looks like it, as you said it's the minimum size of the program which changed. It was 150 kb using link.exe from VisualStudio but with polink.exe it's more like 450kb. Nothing to hide here and it's perfectly reasonable by nowadays standards considering there is still ZERO external DLL dependencies for created exe (which is the most important point IMHO).

exactly that

personaly i use some other competor solutions for stuff which exe STARTS from 2.8mb (simpel hello world) and is still ok ! noone ask noone notice
only psychology helps, and some benchmarks in online bloggers "comparison"

[DeanH]

I am currently breaking these big include library files down into many small pbi files, only included when needed

"C Backend" checks for unused functions and never adds them to the compiled file.

So that's it! I noticed the C-compiled programs were quite a bit smaller. However, the Coretex security system used by schools in South Australia (my employer and over 400 of my customers) completely blocks all 32 and 64-bit exe's PB C-compiled. Claims they contain Wildfire. I found the same problem with Cylance, used in the state of Victoria (600+ customers). I have not encountered this problem with the ASM compiled exe's. (Same source code.) In fact the 6.10 ASM compiled exe's seem much less likely to generate false positives, which has helped. State government based departments mandate particular security systems and I am in no position to argue or tell them otherwise. Instead I have to do what I can to work around these tempermental AV systems. Honestly, file size isn't a big deal. I just personally prefer a program to contain only what it needs. I would very much like to see some type of auto-include system in PB where I can have a bunch of small source code files with my own functions that are automatically included if I use them. Maybe a pre-compiler, but I don't know how to hook that in.

[AZJIO]

I would very much like to see some type of auto-include system in PB where I can have a bunch of small source code files with my own functions that are automatically included if I use them.

Include Helper
pbOptimizer

[BarryG]

PureBasic version 6.10 is generating files that are five times larger than those produced by version 6.04.

Do you really want to get p*ssed off? Check this out: the following single line of code in PureBasic 3.92 vs 6.10:

Code: Select all

LockWorkStation_()

Exe for 3.92 is 2 KB (2,048 bytes).
Exe for 6.10 is 483 KB (495,104 bytes).

That's a 24050% increase in size for the same program that does the same thing.

This is an extreme example, but it shows that if you want smaller exes, then use an older PureBasic if you can. It's what I do for small simple tools.

[juergenkulow]

File size of BarryG's mini program with different versions of pbcompiler, pbcompilerc (all x64):

Code: Select all

28.04.2024  17:06             3.584 LockWorkStation431x64.exe
28.04.2024  17:24             3.584 LockWorkStation461x64.exe
28.04.2024  17:25             3.584 LockWorkStation511x64.exe
28.04.2024  17:26             3.584 LockWorkStation562x64.exe
28.04.2024  17:37             3.584 LockWorkStation571x64.exe
28.04.2024  17:42             3.584 LockWorkStation600x64.exe
28.04.2024  17:44             5.120 LockWorkStation603x64.exe
28.04.2024  17:38             6.144 LockWorkStation600Cx64.exe
28.04.2024  17:46             6.144 LockWorkStation603Cx64.exe
28.04.2024  17:49           496.128 LockWorkStation610Cx64.exe
28.04.2024  17:47           496.640 LockWorkStation610x64.exe

[moricode]

Indeed it's not 5 times larger, but for small programs it looks like it, as you said it's the minimum size of the program which changed. It was 150 kb using link.exe from VisualStudio but with polink.exe it's more like 450kb. Nothing to hide here and it's perfectly reasonable by nowadays standards considering there is still ZERO external DLL dependencies for created exe (which is the most important point IMHO).

exactly that

personaly i use some other competor solutions for stuff which exe STARTS from 2.8mb (simpel hello world) and is still ok ! noone ask noone notice
only psychology helps, and some benchmarks in online bloggers "comparison"

This is the problem of the modern day , things get bloated and bloated and most people do not care about because the internet is fast , the thumb drive is big , the hdd is super giant, the RAM memory is cheap and huge size , so one day , a simple hello world may become 28mb or even 280mb in size , and most people think it is ok and only need to upgrade their hdd, Ram , internet and CPU , and operating system (also getting bloat by multi giga bytes ).

This is happed now in the android world, a very simple app in play store take 50 to 100 MB to download , even some non game app need 200MB in size , what is inside that ?

i have get one android app from developer and study (58MB for release mode ) , peep inside and see , all inside are rubbish , real code is 200KB only .

What you say ?

[moricode]

my work place has installed a government certified accounting and payroll last year, it come with a 3.9GB installation files , who knows what is inside the multi GB of data install along size after decompressed ?

what interface or calculation algorithm needed multi GB of program size ? for game it may need graphic data and video animation and multi stage game data set , but , come on , what is multi giga bytes for an accounting software ? may be giga bytes of help file perhaps ?

bloated , bloated , bloated world , geting more bloated for the AI age now.

one of the microsoft SSMS management interface , installer file is 900MB ~1GB , what is the size decompressed ? what cpu instruction need GB of code ?

[jacdelad]

PureBasic is aimed to be independent from installed components of the target OS. Speaking for Windows you can emulate most commands by using Windows API, which would make the program small, but creates dependencies over the Windows version.
Upgrading the internally used components naturally leads to bigger programs, because said components grow over time too. So, while there still is room for creating smaller programs, it is an evolution process for programs to grow over time and with new versions of the programming language.

Fred could create two versions of PureBasic, one the way it works now and one without the internal libs (small program, but dependencies). I don't think that would be a good step and would mostly create unnecessary work for Fred.

[Michael Vogel]

...if you want smaller exes, then use an older PureBasic if you can.

Right, and most of the time this is the best way for using less memory as well (for auto start tools, system drivers, etc.)
But in certain situations it gets a little bit more complicate - actually I am playing around with statusbar fields which seem to act differently in nearly every version of Purebasic

Code: Select all

If CreateStatusBar(#StatusBar,WindowID(#Win))
	AddStatusBarField(ScaleUp(200))
	AddStatusBarField(#PB_Ignore)
	:
	CompilerIf #PB_Compiler_Version<600
			ProgressBarGadget(#ProgressBar,ScaleUp(10),4,180,ScaleUp(16),0,100)
	CompilerElse
		CompilerIf #PB_Compiler_Backend=#PB_Backend_C
			ProgressBarGadget(#ProgressBar,ScaleUp(10),4,ScaleUp(180)-40,ScaleUp(16),0,100)
		CompilerElse
			ProgressBarGadget(#ProgressBar,ScaleUp(10),4,ScaleUp(180),ScaleUp(16),0,100)
		CompilerEndIf
	CompilerEndIf
	:
EndIf

[Lord]

https://www.purebasic.fr/english/viewto ... 81#p619981

[idle]

https://www.purebasic.fr/english/viewto ... 81#p619981

Recursive decent