PDA

View Full Version : Giant .exe files



arthurprs
01-09-2007, 04:29 PM
I instaled Lazarus here, changed the compiler to FPC2.1.4 rebuild the LCL but everything that i compile gets a giant size "8.4mb" :shock: :shock:

only here ?
how to solve it ?

Legolas
01-09-2007, 04:40 PM
That's a FAQ (http://wiki.lazarus.freepascal.org/Lazarus_Faq#Why_are_the_generated_binaries_so_big. 3F)
:wink:

LP
01-09-2007, 06:00 PM
If I remember well, you can reduce the size by stripping debug info and enabling crosslinking. You will still get a *large* file, but it's a "sensitive" subject where FPC guys get very emotional, and last time I've mentioned it, got a knife in my back, so... be careful! :D

JernejL
01-09-2007, 07:00 PM
[quote="Lifepower"]If I remember well, you can reduce the size by stripping debug info and enabling cross]

imo they should by default use optimized settings and store debug info separatedly :|

arthurprs
01-09-2007, 07:51 PM
Thx for the replys, now 900kb :P

dmantione
01-09-2007, 08:02 PM
imo they should by default use optimized settings and store debug info separatedly :|

Already supported. However, there exist no debuggers that can read such separate debug info.

WILL
01-09-2007, 08:29 PM
I think that your size issue is more related to Lazarus than FPC.

Somehow Lazarus just makes bigger EXE files even without the LCL involved.


Already supported. However, there exist no debuggers that can read such separate debug info.

Isn't there a FPC-specific debugger being worked on right now?

farcodev_
01-09-2007, 11:38 PM
for size problem in last issue try UPX :D

WILL
02-09-2007, 01:41 AM
for size problem in last issue try UPX :D

Yup! This is a popular way to get rid of the large size of the exe. However, I've discovered while doing this myself that if you UPX your executable it won't compress as small via ZIP or RAR.

So like all things there is yet more trade-off.

Robert Kosek
02-09-2007, 01:45 AM
However, I've discovered while doing this myself that if you UPX your executable it won't compress as small via ZIP or RAR.Of course it won't compress any smaller because you just compressed it. Almost all compression schemes do not compress well in successive compression algorithms. Just like JPEG and PNG images with BZip2 increasing up to 50% in size.

WILL
02-09-2007, 02:15 AM
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_
02-09-2007, 01:16 PM
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
02-09-2007, 06:28 PM
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
03-09-2007, 02:39 AM
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
03-09-2007, 10:44 AM
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
04-09-2007, 07:57 PM
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:
http://host-17-99.imsys.net/_share/laz_bat.png

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

marcov
28-10-2007, 11:00 AM
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).