Lazarus

Programming => General => Topic started by: triple-r on January 27, 2011, 06:57:53 pm

Title: Size of executables
Post by: triple-r on January 27, 2011, 06:57:53 pm
Hi everybody,
I'm somewhat new in using Lazarus. For several years my favorite development system was Delphi6 - and it always fits my needs. But now I have to deal with complete unicode based apps, what Delphi6 does not support with the standard VCL components. So I tried to use Lazarus instead. Everything works fine - and I was enthusiastic while trying it out! But then I was really shocked when I recognized that a simple Win32 app with only an empty window (without any additional components) was compiled to an executable of more than 12 MB in size. The same poor Delphi6 executable is of some 10% of this size. Is there anything with the compiler or linker I should configure better or is there always a kind of a "runtime engine" linked into the app? Every hint from you as experienced Lazarus experts is highly appreciated.
Title: Re: Size of executables
Post by: typo on January 27, 2011, 07:03:27 pm
http://wiki.lazarus.freepascal.org/Lazarus_Faq#Why_are_the_generated_binaries_so_big.3F
Title: Re: Size of executables
Post by: cpalx on January 27, 2011, 07:05:47 pm
besides

http://wiki.lazarus.freepascal.org/Size_Matters

http://wiki.lazarus.freepascal.org/File_size_and_smartlinking
Title: Re: Size of executables
Post by: triple-r on January 27, 2011, 07:47:05 pm
Wow, thanks a lot for your help. I also thougt about debug infos, but I couldn't find any config information to exclude debug infos from the binary. But with your hint it works! With the "strip command" the size of the test app reduces from 12 MB to 1.6 MB.

Only, opposite of the FAQ (<quote>"You can use a program called "strip" to remove the debug symbols from the executable file. It is located under lazarus dir lazarus\pp\bin\i386-win32\. </quote>)

in my case the "strip.exe" was located under lazarus\fpc\2.2.4\bin\i386-win32\. But at last - the problem is solved. So the Lazarus community got a new fan now using this great development sytem from now on.
Ray
Title: Re: Size of executables
Post by: Blaazen on January 27, 2011, 07:48:32 pm
I can add here an example from real life.

My (still unfinished) project (Lazarus + Qt):

more than 31000 lines (more than 1000 methods)
more than 1000 components (incl. TMenuItems and TActions) on 7 Forms

Compiled: 18.6 MB
Stripped: 6.9 MB
(I use only external program "strip" for it, I don't use any smartlinking and compiler options because my applicateion is still under development. I will do it when finished.)
I tried archives (tar, gunzip and zip give 1.8 MB; 7z gives 1.2MB). UPX is not recommended.

Archived size is OK when you want distribute on Internet.
(BTW I tried IcoFX  (Delphi app. for drawing icons) under Wine and its setup.exe is 1.5 MB. Unpacked (installed) directory is 3.7 MB.)

You can see that filesize is not big problem especially for big application. Start size is bigger but grows slowly in my opinion.



Title: Re: Size of executables
Post by: Scoops on January 27, 2011, 07:50:40 pm
Hi,

Try From the main menu:

'Project > Project Options > Compiler Options > Linking'

If Checked - Uncheck - 'Display Line Numbers In Run-time Error Backtraces'

After that use upx to compress the application

Hope it helps

Bye
Title: Re: Size of executables
Post by: typo on January 27, 2011, 07:55:38 pm
File size seems to be a big problem for beginners, but it is not.
Title: Re: Size of executables
Post by: triple-r on January 27, 2011, 08:07:01 pm
Hi Blaazen,
<quote>"Start size is bigger but grows slowly in my opinion."</quote>

you're right. As I converted my recent (big) Delphi project to Lazarus the binary size increases from the 12 MB (empty Window as starting point) to just 16 MB, although I added a thousand lines of code and a lot of visual components. So I can confirm that the size grows very slowly from the starting point.
Title: Re: Size of executables
Post by: triple-r on January 27, 2011, 08:18:57 pm
@ typo:
"File size seems to be a big problem for beginners, but it is not."

For distributing executables from servers the file size is simply a traffic problem on the net. But with the "strip" command the problem is already solved. It's not a question of real "beginners" but a question of beginners in trying out another development system without having a complete user documentation. Just learning by doing...
Title: Re: Size of executables
Post by: marcov on January 27, 2011, 08:20:47 pm
@ typo:
"File size seems to be a big problem for beginners, but it is not."

For distributing executables from servers the file size is simply a traffic problem on the net. But with the "strip" command the problem is already solved. It's not a question of real "beginners" but a question of beginners in trying out another development system without having a complete user documentation. Just learning by doing...

These are the typical excuses people try to find to justify an emotional shock when seeing a binary that is bigger than the one from a ten years old tool. Try to step over this, and only mention such thing when you really established it is a problem.

In reality, debug information is very compressable, and most http2 traffic is zlib compressed afaik, and obtaining quality tracebacks are more important than a bit of traffic (and it is indeed only a bit, compressed)
Title: Re: Size of executables
Post by: xenblaise on January 27, 2011, 08:32:05 pm
strip --strip-all project1.exe
upx project1.exe

Size of executable is like Delphi now :D and is faster than Delphi 8-)
Title: Re: Size of executables
Post by: typo on January 27, 2011, 08:41:24 pm
Indeed, if was not so fun to see what beginners say about the file size...
Title: Re: Size of executables
Post by: triple-r on January 27, 2011, 09:00:41 pm
@marcov:
"These are the typical excuses people try to find to justify an emotional shock when seeing a binary that is bigger than the one from a ten years old tool."

I do not want to excuse anything. I've got a question - I've got an helpul answer. That's all.

@typo:
Indeed, if was not so fun to see what beginners say about the file size...
Please feel free to provide your further remarks. But thanks again for yor previous help. 
Title: Re: Size of executables
Post by: garlar27 on January 27, 2011, 09:05:54 pm
I think it's because beginners are used to smaller executables because in other languages the real binary size is hidden inside Libraries (like visual basic does) or by the interpreter or by Virtual Machines.

Then comes the surprise and the  ... complains.
Title: Re: Size of executables
Post by: triple-r on January 27, 2011, 09:13:26 pm
Sorry, garlar27, but not in this case. But I'm logging out now. Bye, everybody...
Title: Re: Size of executables
Post by: typo on January 27, 2011, 09:17:16 pm
@ triple-r
It has actually a very simple solution, although the "problem" is very remarkable. I suspect that is on purpose.
Title: Re: Size of executables
Post by: garlar27 on January 27, 2011, 09:39:27 pm
@triple-r:
I know you didn't have complained with file size because you never said the thing like "you should do it better..." or many other ways people usually complains.

I was a beginner too and once I've been questioned about file size I was clueless %)! I've never paid attention to binary size until that moment  :o!!!

Frankly it was a shock. But after reading the FAQ and the forum I knew why things where like this.

I should started my post with @someone (I thought typo was wondering why people keeps asking this, but guess what, I misunderstood what typo said  :-[ :-[ :-[).
Title: Re: Size of executables
Post by: typo on January 27, 2011, 09:46:35 pm
Of course I have English as a second language, but I do wonder why people say that. Quick answer: they don't read the FAQ. On LazarusBrasil site, FAQ page views are on 7th position.
Title: Re: Size of executables
Post by: garlar27 on January 27, 2011, 10:02:14 pm
English is my second language too  :D
Title: Re: Size of executables
Post by: xenblaise on February 02, 2011, 04:55:59 am
The size matter if the romance is bad  >:D JOKE ONLY
Size doesn't matter, the important?,  is how you deploy your application to other platform with fast load and good memory handle. :D

Just curious about JAVA, why they still develop software applications using it,  as we know JAVA is very slow application process, heavy to handle memory,  even until now, there's no gain with there pain.
But as I lookout, JAVA will be dead 3 to 5 years from now, and that was mentioned from a few forum I've read also. 8-)
Title: Re: Size of executables
Post by: r_1gm on February 02, 2011, 07:16:56 am
Hi all,

@xenablaise and the others, i using FPC/Lazarus and also Java, maybe we should look to the other side, in Java you can use Object without knowing about pointer, good "STANDARD" collection library, good library structure(thank you package) and naming so newbie can look to the library and learn easily, you get almost complete "STANDARD" library when you download that bloat SDK and it's works it's just works, and many good other thing, maybe FPC/Lazarus can learn some from Java in some place, we need open up our mind if we want FPC/Lazarus to be success full  8-).

And Java is not slow as before(yes the start-up is slow, but is very improved now and watchout for Java 8 ), just give it enough memory and some basic knowledge you will see Java is not like you see.

Cheers
Title: Re: Size of executables
Post by: TurboRascal on February 02, 2011, 01:44:31 pm
UPX is not recommended.

I'd just like to step in here to add another vote against UPX since so many advices is given to use it  ;D
Title: Re: Size of executables
Post by: Dibo on February 02, 2011, 03:30:42 pm
This things about size remind me my post:
http://www.lazarus.freepascal.org/index.php/topic,10535.0.html

LCL interface is unrivaled on most normal projects where size have no matters (e.g. multiplatform desktop application, ERP, databases etc). I do not know how others, but I often write some specific applications where I don't need cram whole LCL into executable.
Example:
- simple application for Windows Mobile. I think 2MB exe is heavy for mobile phones (technology is constantly moving forward but it is still big). In this case I always use KOL-CE (key object library) instead of LCL
- non visual plugin for internet browser or instant messenger where I need only one "about form". Without form, plugin have ~70 kB (pure WinAPI and FPC classes). After add LCL form, executable increase to 2MB. In this case I use CreateWindow in WinAPI instead of LCL.

What I want to say is that is missing some wrappers for specific system low level API (e.g. WinAPI) for applications with simple GUI. Using pure WinAPI is tricky and takes too much time. Good example of wrapper is fpGTK unit. This same simple wrapper would be great on windows :)
Title: Re: Size of executables
Post by: Leledumbo on February 02, 2011, 06:04:58 pm
Quote
In Java you can use Object without knowing about pointer, good "STANDARD" collection library, good library structure(thank you package) and naming so newbie can look to the library and learn easily, you get almost complete "STANDARD" library when you download that bloat SDK and it's works
Do you need to know about pointer when using Object Pascal classes? ;)
I agree with the rest of your statement. Java standard library (the collections framework actually, the others are sometimes too bloated) is well designed, the package system also allows duplicate filenames (with different semantics, of course) in different packages. There's already a discussion about allowing unit names to be like that (this.that.whatever.xxx), but it didn't seem to come to an end AFAIR. From what I see, it's basically a choice. As opposed to unit system, Java package system allows good structuring but makes refactoring difficult. The change in package hierarchy would affect applications, while in unit system the change is transparent.
Quote
What I want to say is that is missing some wrappers for specific system low level API (e.g. WinAPI) for applications with simple GUI. Using pure WinAPI is tricky and takes too much time. Good example of wrapper is fpGTK unit. This same simple wrapper would be great on windows
This is very common happened on many C/C++ projects and in the end, they almost likely end up in LCL design way. And it often ends in bad performance because it's not designed from ground up to support many backends. Take a look at wxWidgets, GTK+, QT. They startup slowly on their non-native (i.e. first backend they support) targets (it happened as well to LCL when you use them). Anyway you could create your own if you still think it's necessary. I ever built one, too. But from time to time, my requirement grows, refactoring everywhere, and I finally decided to go back to LCL.
Title: Re: Size of executables
Post by: marcov on February 04, 2011, 12:02:09 pm
@ triple-r
It has actually a very simple solution, although the "problem" is very remarkable. I suspect that is on purpose.

Afaik:

* In general Unix has always done it this way. The logic is that you more often debug than release. IOW you generate debuginfo always, and use the strip command to ship the debugged version (exactly the same build, but without debuginfo) to the customer. You can also ship  the binary with debuginfo to selected (knowledgable) users to e.g. get tracebacks with meaningful data.

* The debuginformation in a separate binary bit is still in development (new in 2.4.x and requires newer binutils), and not yet completely crossplatform, hence not default yet. (not that I think that it would be better, but it at least would get rid of the enormous amounts of questions)

Title: Re: Size of executables
Post by: marcov on February 04, 2011, 12:11:24 pm
... the package system also allows duplicate filenames (with different semantics, of course) in different packages. There's already a discussion about allowing unit names to be like that (this.that.whatever.xxx), but it didn't seem to come to an end AFAIR. From what I see, it's basically a choice. As opposed to unit system, Java package system allows good structuring but makes refactoring difficult. The change in package hierarchy would affect applications, while in unit system the change is transparent.

I've looked into this in the past, and it is quite complex. Both the Java way as the Pascal (units) way are heavily related to the way that the compiler finds its files, and knows what files to recompile, and how files are allowed to reference eachother (how dependancies are solved)

Changes to the unit system therefore risk the chance that the current model (  fpc  -Fu/somedirectories <mainprogram> ) becomes impossible, and you need a full project file, and a full redesign of anything that relates to units (including interface-implementation separation, totally breaking compatibility).

The Delphi (originally .NET) workarounds for dotted filenames are ad-hoc (as they originally were only meant for a brief conversion phase from native-.NET, a conversion that never happened since users prefered to stick with native or go to MS C# directly), not internally consistent, and not very useful, while at the same time hugely complicating the compiler.

Of course most of the advocacy for the Java system never really detailed their proposals, they "just" wanted to use dotted names etc. But you either have to go all the way (since the Java system, whether you like it or not IS consistent), and ditch the unit system completely, or keep the current way.

Personally, I see two competing systems, and while I have a preference for the Pascal way (more usable without IDEs), the Java system is not bad.

But even when I had a preference for the Java system, I'd rather keep the current system, since the turmoil of a fullblown conversion would be worse than whatever   benefits.
Title: Re: Size of executables
Post by: xenblaise on February 04, 2011, 04:55:34 pm
r_1gm;

thanks, good advice.

Quote
From what I see, it's basically a choice. As opposed to unit system, Java package system allows good structuring but makes refactoring difficult. The change in package hierarchy would affect applications, while in unit system the change is transparent.
got this one :D