Giant .exe files

[WILL]

Yeah, but the funny thing is that if you leave the EXE at it's full size and just RAR/ZIP it, it's smaller than if you UPX it and ZIP/RAR it after.

It's something to consider...

[farcodev_]

Hmmm, let's do some experiences :? :twisted:

FARColony.exe = 2,400,768 bytes

FARColony.rar=794,430 bytes

FARColony.exe UPXed= 783,360 bytes + the hability to be launched directly as a standard exe, not as your .rar don't forget that WILL :shock: :lol:

[WILL]

Hmm post me a copy of your exe? I'd like to run a test myself.

Method 1: freshly compiled EXE -> UPX at best setting -> RAR/ZIP at best setting

Method 2: freshly compiled EXE -> RAR/ZIP at best setting


One of the key factors to making the exe smaller is download size. With computers of 60-400 GB drives 2 megs is hardly worth worrying about when it's sitting on your drive. However you still have to bring it through your internet connection such size flexibility isn't there yet. Esp. in some places where they don't have the kind of great broadband services that they have here and other places.

Of course you can always leave it uncompressed and use the worst zip/rar compression possible. Then they'll think that by sheer size they are getting great value for their dollar. :lol:

[LP]

You can also store your EXE in ZIP and let the users doubleclick on the file and run it on WinXP. Same thing with UPX, just the process is simplified.

I think it is a good practice:

* Storing many files in a single archive, so they don't take much disk and MFT space.

* As a consequence, there is less fragmentation on disk, thus improved performance for the system as a whole.

I think it is a bad practice:

* Storing one file in archive, then decompress it each time you run (you either occupy disk and/or memory for that), just for the sake of showing that large FPC/Lazarus generated files aren't that large.

In either case, the large generated file will still be relatively big when you publish on Internet, so why bother? My entire argument is against using UPX - as I already said, I think it's a bad practice.

If the application size would be an issue for me, I would either think on 1) ignoring the problem and accepting the file size or 2) using different development tool.

[Almindor]

Depending on platform FPC produces these sizes when configured properly for size (-XX -Xs)

Win32:
Hello world: 17kb
LCL Form: ~1.5mb (IIRC, this is from memory, need latest fpc with internal linker)

Linux:
Hello world: 23kb
LCL Form: ~2.2mb

The problem of size is 2 fold:

1. GNU ld isn't exactly efficient (speed and result size), however in win32 this is already fixed in latest fpc
2. Debug info cannot be separated because GDB doesn't support it. If you want to help, write a debugger.

As for defaults, I think it's sane to set defaults to debug output. It's not normal to develop without debug info. Once you're happy with the result, just set it to release settings and you're done.

Besides up to 5mb binaries are pretty normal nowadays even with software which doesn't use smartlinking. If you want to know what others take, look at all the .dll files they bundle with the .exe and add that up to see real size. It's in the 10s of MB.

[Chebmaster]

AFAIR, the strip isn't 100% effective - i.e. you get bigger exe after compiling from Lazarus + stripping than from just compiling in FPC.

For the non-visual programs I always use this:


Such way you also get much more flexibility in your project handling.
For Windows it's the same, only you use .bat

[marcov]

See also

http://wiki.freepascal.org/Size_Matters

Some other points
- For the windows platforms, all old experiences have to be reviewed with the arrival of 2.2. The internal linker changes a lot.
- Some older windows releases were released with a linker that didn't properly stripped when using -Xs (manually stripping worked fine though).