PureBasic Forums - English

Are there any tricks for keeping file size down for a PB project?
I just hit 101 kb and have only half of my character creation system finished. I'm worried once all the dialog, custom fonts, and locations are completed its no longer going to fit on a 1.44mb floppy.

for executable or dll you could use UPX https://upx.github.io/
however, some AV will probably give a false positive on exe's packed with UPX

Vernostonos wrote:... its no longer going to fit on a 1.44mb floppy.

Excuse me, it's the year 2020.

Vernostonos wrote:Are there any tricks for keeping file size down for a PB project?
I just hit 101 kb and have only half of my character creation system finished. I'm worried once all the dialog, custom fonts, and locations are completed its no longer going to fit on a 1.44mb floppy.

If it is just for the storage of your portable working files I would suggest using a thumb drive. Is there any reason why you would be limited to only a 1.44 mb floppy?

If it is for the executable that you will produce from the project then a smaller file that loads and uncompresses the main file before running it may be the way to go.

jack wrote:some AV will probably give a false positive on exe's packed with UPX

That doesn't happen anymore. The AV just unpacks it. Packed/unpacked is the same AV results. I've done LOTS of tests in this area.

You care about the exe size which made by PB?

You will find that as long as you do not need additional PB libraries, the file will not grow much. The libraries is what increases the size. Unless you have a ton of text in your file (maybe compress/uncompress at runtime). But I would wait with that till completion and only if necessary... If that's the case, then the text should move to an external file anyway to simplify maintenance or even translation.

Use 'bits' or the BriefLZ packer to grunch down fonts and graphics.
Break down your code in procedures -> reuse code as often as possible.
Use ascii when storing strings - unicode is a waste.

Good luck

Edit:
I really like such projects and i totally see that u need the floppy.
Having the fastest and smallest code possible is a lost virtue.

What is your software supposed to do? What is your target operating system?

Mijikai wrote:Having the fastest and smallest code possible is a lost virtue.

The good old times of manipulating exe headers to save a few bytes on disk I remember some people invented their own assembly language for size competitions done by Hugi.

Why are people replying to a post from last century?
Usually spam bots respond to those.

I had trouble loggin, in to post this. It gave me a "too many failed attempts" error so there are spammers trying to hack into the Forum.

Norm.

normeus wrote:Why are people replying to a post from last century?

What? This thread is only a day old.

Mijikai wrote:Having the fastest and smallest code possible is a lost virtue.

It's not always the smallest code that is the fastest. In fact many codes can be made faster when you use a better and also bigger structure and better algorithms. Compare Bubblesort with Quicksort.

NicTheQuick wrote:

Mijikai wrote:Having the fastest and smallest code possible is a lost virtue.

It's not always the smallest code that is the fastest. In fact many codes can be made faster when you use a better and also bigger structure and better algorithms. Compare Bubblesort with Quicksort.

+1，general rules in programming,either room,or speed.

NicTheQuick wrote:It's not always the smallest code that is the fastest. In fact many codes can be made faster when you use a better and also bigger structure and better algorithms. Compare Bubblesort with Quicksort.

Do you think they did not know that, whats your point?
Hardware has changed drastically so there is not the same incentive/requirement anymore to get the best result in both areas.

Mijikai wrote:

NicTheQuick wrote:It's not always the smallest code that is the fastest. In fact many codes can be made faster when you use a better and also bigger structure and better algorithms. Compare Bubblesort with Quicksort.

Do you think they did not know that, whats your point?
Hardware has changed drastically so there is not the same incentive/requirement anymore to get the best result in both areas.

Of course not all programmers know that. That's the reason I wanted to point that out more specifically. It's just not true, that's all.

But I agree that today's code bases often are way more bloated then their need to be. So in general you need the right balance to use CPU caches, branch predictions and the best instructions the CPU has to offer in a efficient way. Of course, on small microcontrollers with 1 MB of flash memory or less you need to look at each bit individually to get the smallest executable possible. But that's a totally different way of programming than on modern computers with more Cache than these microcontrollers have memory available.