Bookstore

Recent

Author Topic: Size of executables  (Read 16214 times)

typo

  • Hero Member
  • *****
  • Posts: 3051
Re: Size of executables
« Reply #15 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.
« Last Edit: January 27, 2011, 09:23:24 pm by typo »

garlar27

  • Hero Member
  • *****
  • Posts: 635
Re: Size of executables
« Reply #16 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  :-[ :-[ :-[).

typo

  • Hero Member
  • *****
  • Posts: 3051
Re: Size of executables
« Reply #17 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.

garlar27

  • Hero Member
  • *****
  • Posts: 635
Re: Size of executables
« Reply #18 on: January 27, 2011, 10:02:14 pm »
English is my second language too  :D

xenblaise

  • Sr. Member
  • ****
  • Posts: 358
Re: Size of executables
« Reply #19 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-)

r_1gm

  • New Member
  • *
  • Posts: 26
Re: Size of executables
« Reply #20 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

TurboRascal

  • Hero Member
  • *****
  • Posts: 672
  • "Good sysadmin. Bad programmer."™
Re: Size of executables
« Reply #21 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
Regards, ArNy the Turbo Rascal
-
"The secret is to give them what they need, not what they want." - Scotty, STTNG:Relics

Dibo

  • Hero Member
  • *****
  • Posts: 1048
Re: Size of executables
« Reply #22 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 :)
« Last Edit: February 02, 2011, 03:33:15 pm by Dibo »

Leledumbo

  • Hero Member
  • *****
  • Posts: 8162
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: Size of executables
« Reply #23 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.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8052
Re: Size of executables
« Reply #24 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)


marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8052
Re: Size of executables
« Reply #25 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.

xenblaise

  • Sr. Member
  • ****
  • Posts: 358
Re: Size of executables
« Reply #26 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