Hello everyone!

As stated in this article http://wiki.freepascal.org/Size_Matters "Lazarus apps on Windows are about 500k, but quickly grow to 1.5 MB" however I cannot made Lazarus to build empty application less than 1.8 MB. I've enabled option "Link Smart" at "Linking" tab of compiler options as well as "Strip Symbols From Executable" and disabled "Display line numbers in runtime..", however nothing helps to make empty application less.

Does this mean that 1.8 MB is the size of empty Lazarus application now? Or I do something wrong?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090402/11b4c7a3/attachment.html

Igor Tkachenko wrote

Does this mean that 1.8 MB is the size of empty Lazarus application now?

Yes. For an application that includes the LCL.

Or I do something wrong?

No.

I think the size of 500 kB was too high from the beginning, I never saw it smaller than 1 or 1.2 MB, but the size has grown since that article was written.

Vincent

2009/4/2 Igor Tkachenko :

Does this mean that 1.8 MB is the size of empty Lazarus application now? Or I do something wrong?

Depends on the toolkit used with Lazarus...

Under Linux I just tried with the pre-alpha fpGUI Toolkit. A simple application with only a Main Form and no other components. One used LCL-fpGUI and the other used fpGUI directly (no LCL). It's amazing how much extra LCL adds.

LCL-fpGUI = 2,530,336 bytes

fpGUI directly = 392,960 bytes

Regards,
- Graeme -

Dear Igor:

I had the same problems, but I remedy following this rules:

I prepare a .bat with three sentences as follow:

strip.exe LoadExcelFile.exe
upx.exe LoadExcelFile.exe
LoadExcelFile.exe

and in the same folders where are all the files there are this two: strip.exe and upx.exe (a compactor)

I execute the program with Ctrl+F9 and when finish, I go to the folder and execute the .bat that first take out all the debuggings instrucctions, compact the .exe and finnally, excute it to see how it works.

Generally, the .exe files take 500 to 800 kb, depending how many images.

let me know your advances,

yours,

Ing. H?ctor F. Fiandor

---------------------------------------
Red Telematica de Salud - Cuba
CNICM - Infomed

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090402/800b34f6/attachment.html

The application is not empty. If you check the symbols inside the application you will see that almost all LCL components are added, and PNG support, XML library, etc, etc, etc, even if not used. The smartlinking is simply not yet good enought to remove those parts.

This isn't such a big deal because hello world applications are useless, in real world applications you will need to use multiple components, have graphics support, use xml, etc, and those are already there, so your EXE size won't grow when you need them.

And this has been debated 1 million times before, please search in the mailling list archives.

Felipe Monteiro de Carvalho wrote

And this has been debated 1 million times before, please search in the mailling list archives.

This also means that problem of big executable size worries developers. Maybe we need to research more how to make our executables smaller.

Best regards,
Paul Ishenin.

Try building your app with:
-O2 -Os -XX -CX -OpPENTIUM

gives 1.5 MB (you also need to recompile the LCL with those options)

or look at http://wiki.freepascal.org/Whole_Program_Optimization

Best Regards
Martin

If you remove icon from project your application size reduce from 1.8 to 1.5 MB.

Best regards,
Paul Ishenin.

Especially so if you are targeting embedded devices, smartphones etc... Size matters in this case, but not so much for desktop applications.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

This isn't such a big deal because hello world applications are useless, in real world applications you will need to use multiple components, have graphics support, use xml, etc, and those are already there, so your EXE size won't grow when you need them.

I had many times the need to make a small application that did some few basic tasks without using multiple components, having any kind of great graphics support, use xml and other things, which is common for making front-end GUI programs to command-line programs or libraries and Lazarus is ideal for this. In the end I just eat the extra garbage (because that's what they are when the program doesn't use them but carry them around) but I would prefer that this wasn't the case. As said by Paul, since this is something that is asked so often, it means people need it and research should be done on it.

Of course personally I would prefer dynamically linked packages so I can break large programs in DLLs and made (dynamic) plugins that use LCL possible much more than that.

Kostas "Bad Sector" Michalopoulos

An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090403/889c9291/attachment-0001.html

Hello Felipe,

Yes, I know that "size isn't a big deal in a real world", but this is correct just for some kind of GUI applications. From version to version LCL application executables grows in size. What size of empty applications will produce Lazarus in 2 years? 5 MBs or 10 MBs? :) If LCL executables became so large in size Lazarus and LCL will became inappropriate tool for a part of applications - for system utilities.

I'm developing system utilities (http://safelyremove.com/, http://lockhunter.com/) and I know from feedback that users of such system tools expect to see small executables rather than big executables. If a system tool like ours have size larger than 2 MBs (it can be easiliy achieved by adding a few forms) we will start to receive letters with questions: "Why your program have so big executable? Have you added some malware there?".

Of course the most important matter for system utilities is their memory consumption, it's worring users much more often, however a size of executables is also a big deal for such tools.

P.S.
If a thing debated 1 million times before this means this is a VERY BIG DEAL and required by many others :)

Graeme,
I also downloaded KOL and MCK GUI kit and I created an empty application with the size of 200 KBs (70 KB without icon). However KOL have a very-very minimalistic approach. They even do not use Object Pascal classes and this is not object oriented library, because to manage all the objects you have to invoke separated functions and procedures. It makes "learning curve" higher for any new developers of my team, therefore I wouldn't consider KOL.

Anyway thank you for your advice I will try fpGUI.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090403/5c7a35f7/attachment.html

H?ctor,
Thank you for your advice! However using upx.exe just hides but not resolves the problem. Moreover AFAIK upx still doesn't support native Windows 64 code. And the final thing at using UPX causes some troubles. You may read about it here:
http://wiki.lazarus.freepascal.org/Size_Matters#UPX

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090403/688e727f/attachment.html

We have all units listed in the interface section to avoid unit circles. This is needed since the compiler will fail to compile the LCL sooner or later if there are to many circles.

Marc

Sorry for my question, but do all those statements e.g. DebugLN('WARNING: obsolete call to RecreateWnd for %s', [AWinControl.ClassName]); make the exe-file bigger ?
There are thousends of them.

An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090403/1ccb55df/attachment.html

If the wiki article talks about sizes, it DOES NOT include UPX.

Probably the LCL got bigger, or the internal linker is less efficient with smartlinking.

Note that the wiki article probably used windows sizes based on the 2.0.x or 2.1.1 external linker. (with GNU LD eating a GB to smartlink)

Felipe Monteiro de Carvalho wrote

The application is not empty. If you check the symbols inside the application you will see that almost all LCL components are added, and PNG support, XML library, etc, etc, etc, even if not used. The smartlinking is simply not yet good enought to remove those parts.

Note that unneeded parts in an .exe might also be a LCL architectural problem, not necessarily per se smartlinking. Often if units are referenced, init code is run that touches a lot of stuff.

This isn't such a big deal because hello world applications are useless, in real world applications you will need to use multiple components, have graphics support, use xml, etc, and those are already there, so your EXE size won't grow when you need them.

Correct. 1MB is nothing to worry about. 10 MB is not even something to worry about, if it starts swiftly.

????? ???????? ?????:

I think it will not grow to more than 2MB even after 2 years. Moreover I suspect size can go down when we start using native resources.

Best regards,
Paul Ishenin.

2009/4/3 ????? ???????? :

You can answer them that the executables are big because you are using a cross-platform GUI library, and they can check the code of the library.

Maybe they would be happier if we could make the LCL into DLLs. There was some investigation about it, but still far from reality.

Anyway, there is a big deal of psychology here, because I think they would be happier if the executable was 100kb but depended on 24MB of DLLs (like the Qt4 installer for Mac OS X), which is obviously contradictory if you know about the technology.

And now it comes to another point. If you compare the LCL to other cross-platform GUI libraries, like Qt, it's actually much smaller, but with the down side that we still can't make the LCL into DLLs, which can be reused in multiple applications.

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090403/b96abbe7/attachment.pl

Paul Ishenin wrote

I think it will not grow to more than 2MB even after 2 years. Moreover I suspect size can go down when we start using native resources.

Well Paul, it is already way above 2MB! Using Lazarus (trunk) r19175.

LCL-fpGUI = 2,530,336 bytes
LCL-GTK1 = 2,700,452 bytes
LCL-GTK2 = 2,793,732 bytes

This was a single form application with NO other components. Smart Linkable and Smart Linking enabled, Level 2 optimization, icon removed, no debugging information, Strip enabled and for good measure I ran 'strip' manually afterwards.

So with LCL growing daily, the 5MB mark will be hit soon I think. The 2MB mark has come and gone (way before your next 2 years estimate).

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/4/3 Felipe Monteiro de Carvalho :

would be happier if the executable was 100kb but depended on 24MB of DLLs (like the Qt4 installer for Mac OS X), which is obviously contradictory if you know about the technology.

I must agree here. I would much rather prefer a stand-alone application that has no extra requirements like DLL's or SO's. This is what I hated about Kylix 3 application - it was not easy to deploy because the CLX and Qt requirements. To this day I can't simply click on a Kylix application and expect it to run. I need a few of those 6MB SO's files to go with it. This is what I love about fpGUI Toolkit. Much less requirements and I even ran applications I compiled today on Ubuntu 9.04 (beta) on a old RedHat 8 distro in a VM session.

Anyway, to me ease of deployment is much more important that executable size - simply because I only develop for the desktop. :)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I guess paul was talking about the win32 interface on i386-win32.

Vincent

There are more places:
- win32 and wince interface: WndProc procedure
- gtk1, gtk2: event handlers, SetText method

Best regards,
Paul Ishenin.

It is on linux. On windows with strip and no icon it is only 1,5MB. The difference here because of using different api and because of using internal linker on windows.

Best regards,
Paul Ishenin.

And now it comes to another point. If you compare the LCL to other cross-platform GUI libraries, like Qt, it's actually much smaller, but with the down side that we still can't make the LCL into DLLs, which can be reused in multiple applications.

IMO using runtime DLLs should not be a high priority goal. My experience is that updates of such DLLs tend to break older programs. I've been very happy when Delphi allowed me to write self-contained applications, independent from runtime DLLs.

DoDi

2009/4/3 Graeme Geldenhuys :

i get 1,803,196 bytes for lcl-gtk2 (manually compiled with smartlink and -O2). lazarus trunk and fpc trunk.

henry

Which is?

The later was done to keep the code maintainable. Smart linking could be improved a lot, but not without a price.

Btw, I saw expanding RTTI on Verity Stobs and Nick Hodges agenda:

http://blogs.embarcadero.com/nickhodges/2009/02/04/39200

Brr.

In the CG forums it is also often asked, but the problem with those is that there is never any discussion about downsides of new features.

There is another question, which is debug info.I think it's precious to have correct unit/line information in case of application crash in customer computer. That means huge above 33MB applications. I would be glad if debug info could be dumped into separate file AND used by lineinfo and heaptrc in case of exception to show stack trace.Of course as an optional way of distributing application.

Btw, under windows antivirus like Kaspersky is scanning new exe files and in case of large file it can take a minute or more (when debug info is included in exe) ! Imagine a user installed your application and first running it, stuck with a problem and calling you that application is not working.

Regards
Boguslaw

Debug info can be placed in a separate file - you need to use -Xg option for that. I have no idea though whether heaptrc or lineinfo units can work with it but gdb can.

Best regards,
Paul Ishenin.

Hello,

when is dynamic linking in mainstream Lazarus scheduled? we could spread the size of the LCL over a set of DLLs. Small utilities would all share the same DLLs, and have in their EXE file only a couple of hundred Ko.

In any case, manual dynamic linking is possible.

Best regards,
Thierry

Thierry Coq wrote

when is dynamic linking in mainstream Lazarus scheduled?

As soon as somebody implements the needed functionality in FPC. Like packages.

http://wiki.freepascal.org/packages

we could spread the size of the LCL over a set of DLLs. Small utilities would all share the same DLLs, and have in their EXE file only a couple of hundred Ko.

But for only one program the distribution is bigger. And only when compiled with exactly the same version sharing is possible. And of course more programs will need an installer.

The theory is always appealing, but look in practice to systems that have dynamic runtimes and distribute binaries. Version problems are the norm.

In any case, manual dynamic linking is possible.

Is it? How do you avoid the duplication of VMTs and RTL state ?

I strongly agree with Alexey here. The bug in FPC should be fixed and Lazarus source updated to remove unnecessary units from 'uses' clauses.

Not so much for executable size, but for mantainabilty of the source.

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090407/bf9372c6/attachment.pl

Eh... you mean 'no'? Because I argue _for_ 'uses' sections in implementation.

Alexander S. Klenin

Zitat von Alexander Klenin :

Oops. Sorry, then I misunderstood you.

Uses sections in implementation sections are buggy as long as I know fpc. The problems are known but apparently too hard to track and fix. The bugs appear at random and with various degrees depending on platform and fpc version. In some years you think the bugs are fixed, and then they come back. You have been warned: Don't use the imp sections.

I thought this was known:
http://wiki.lazarus.freepascal.org/DesignGuidelines

Mattias

2009/4/7 Mattias G?rtner :

This is the first I here of this. I was always taught to limit the usage of the Interface section's uses clause, so you can prevent circular unit issues. So is FPC the opposite of Delphi in this regards?

I have used FPC since 2.0.2 under Linux and Windows and haven't had any issues. I limit the usage of interface uses clause as much as possible. I believed that is why the smartlinking works so well with fpGUI - I can create a GUI application that is only 340KB in size.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/4/7 Graeme Geldenhuys :

I believed that is why the smartlinking works so well with fpGUI - I can create a GUI application that is only 340KB in size.

Can somebody explain to me why smartlinking works better when a unit is in the implementation section than when it is in the interface section? I thought for smartlinking it doesn't make a difference, the unit is used anyway.

Vincent

No, but the problem is caused by the way fpc stores info in the .ppu Somehow it is possible that the checksum of the interface part stored in the .ppu is affected by the implementation section. When editing sources this can lead to strange results, the compiler might think in some cases an interface is changed or not. When Lazarus started we put a lot in the uses section of the implementation part. When some source was changed, sometimes a 3 or fourtime compile attempt was needed to compile the while LCL, since everytime the compiler thought a unit was changed whil it was not. Restarting compilation (and keeping the existing units) in most cases resulted in a compiled LCL.
To avoid this and to make the LCL usabole as "library", most unit cirles were removed. One way to ensure that is by putting all uses in the interface section.

I have used FPC since 2.0.2 under Linux and Windows and haven't had any issues. I limit the usage of interface uses clause as much as possible. I believed that is why the smartlinking works so well with fpGUI - I can create a GUI application that is only 340KB in size.

It might depend on how you compile fpGUI.

Anyway, back to the subject, I cannot imagine why FPC when smartlinking makes a difference between interface and implementation uses. Especially if you use an external linker, like on linux.

Marc

Maybe because you follow our advice to always do a 'make clean all' on the lazarus sources, which 'solves' the bug in most cases. The bug(s) can not be reproduced easily, but when it appears it is reproducable. The problem is that you need some ppu to demonstrate and you can not feed 100MB into the bug tracker.

The last time happened when Martin added some unit cycles in synedit. Under FPC 2.2.3 it worked most of the time. Under FPC 2.3.1 only a clean rebuild worked.

I was always taught to limit the usage of the Interface section's uses clause, so you can prevent circular unit issues. So is FPC the opposite of Delphi in this regards?

No, no, you are right. The implementation uses section is not buggy per se. But with them you can build the circular unit dependencies. With merely the interface uses sections you can not.
As long as you keep an acyclic hierarchy you can use whatever you like.

When using only interface uses sections you can not even create accidentally a cycle. That's why I recommend to avoid imp uses sections.

I have used FPC since 2.0.2 under Linux and Windows and haven't had any issues. I limit the usage of interface uses clause as much as possible. I believed that is why the smartlinking works so well with fpGUI - I can create a GUI application that is only 340KB in size.

AFAIK smart linking has nothing to do with unit interdependencies. Of course you are right that every unit interdependency makes improving smart linking more difficult.

Mattias

Doesn't it require anyway recompilation of all lcl units with -CX option (smart linkable) ?

Btw a little different question : what is needed to allow lineinfo reading stack trace from external file (in case of exception) for example of the name corresponding to exe name but with different extension. FPC can now dump debug info into such separate file. Such feature would be very useful as compilation option for example.

Boguslaw

Write a lineinfo unit that supports the external file.

Mattias

> I thought this was known: > http://wiki.lazarus.freepascal.org/DesignGuidelines This is the first I here of this.

Me 2.

I have used FPC since 2.0.2 under Linux and Windows and haven't had any issues. I limit the usage of interface uses clause as much as possible. I believed that is why the smartlinking works so well with fpGUI - I can create a GUI application that is only 340KB in size.

Smartlinking is not directly affected by Uses. Instead it's most often the code in used unit Initzialization sections, that makes all related code part of the executable. E.g. when initialization code creates objects or references subroutines, that are not otherwise used by the application code, a smart linker cannot exclude that definitely referenced code.

Similarly virtual methods: they are referenced in the VMT, which again is referenced in every instance of the class. Consequently virtual methods must become part of the executable, as soon as a class typename is used in any way in an application. Static methods, in contrast, can be safely omitted when not referenced anywhere else. IMO.

DoDi

No, but the problem is caused by the way fpc stores info in the .ppu Somehow it is possible that the checksum of the interface part stored in the .ppu is affected by the implementation section.

Just a note: some people think that units can be compiled in one pass - this is not true. The compiler must stop on every Uses clause, and compile at least the interface parts of all the used units. This is why circular unit references are disallowed in the interface section, they would block the compilation of the interface parts of all units in that loop.

IMO there exists a severe design flaw in FPC, when the compilation of the implementation part of some unit can change the checksum of its interface part.

DoDi

Mattias Gaertner wrote

The last time happened when Martin added some unit cycles in synedit. Under FPC 2.2.3 it worked most of the time. Under FPC 2.3.1 only a clean rebuild worked.

FPC 2.3.1 works more unstable here. Try to move property from public to published section, try to add/remove default value to any property and you will have a crash in compiler if you build without clean.

Best regards,
Paul Ishenin.

Isn't it already written? It looks like exeinfo.pp (unit shared by lineinfo and lnfodwrf) supports this feature. Didn't test it though. However, it gets the name of debug info file from the debug section of the executable, so the executable shouln't be stripped in this case.

Regards,
Sergei

Marc Weustink wrote

No, but the problem is caused by the way fpc stores info in the .ppu Somehow it is possible that the checksum of the interface part stored in the .ppu is affected by the implementation section.

Since I started using Lazarus (4+ years ago), I have only two had a checksum issue compiling lazarus. A simple 'make clean' and then recompile resolved the problem. But I actually think the issue was caused due to a FPC upgrade - I can't remember exactly, but am pretty sure.

To avoid this and to make the LCL usabole as "library", most unit circles were removed. One way to ensure that is by putting all uses in the interface section.

OK I'm confused. How does solving circular reference get resolved by putting everything in the Interface section? Doing that is what causes circular reference problems?? Maybe I understand circular reference problems differently to you... this is what I mean:

====================
{ this defines TClass1 }
unit Unit1;

uses
  unit2;
type
   TClass1 = class(TObject)
   private
      FRef: TClass2;
    end;

....
====================

{ this defines TClass2 }
unit Unit2;
uses
  unit1;
type
   TClass2 = class(TObject)
   private
      FRef: TClass1;
    end;

....
=============================

Both classes require each other and can't be compiled. This is what I understand as circular unit references. To solve this you can lump both class definitions in a single unit and add a 'forward declaration' at the top.

OK, I worded that wrong. For smartlinking there shouldn't be any difference if the unit is in the Interface or Implementation section. What is important is if the unit is used or not. I think the reason I can get such small executables, is because every gui component lives in it's own unit. fpGUI doesn't have a StdCtrls or ComCtrls unit which lumps a whole bunch of classes together. And when I create applications I only add the units I really need. This is obviously key.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

In order to break the circles, you must first find them. Move all uses to the interface section and FPC will find them for you.

Doing that is what causes circular reference problems??

?

Yes.

[...] OK, I worded that wrong. For smartlinking there shouldn't be any difference if the unit is in the Interface or Implementation section.

Yes.

What is important is if the unit is used or not.

Only if the unit has an initialization section.

For example simply adding uses Math; without using any part will not increase the exe (using smart linking).

I think the reason I can get such small executables, is because every gui component lives in it's own unit.

This has nothing to do with smart linking. But it helps to keep the keep the exe small without smart linking.
For the LCL this would not help much - see other mails.

fpGUI doesn't have a StdCtrls or ComCtrls unit which lumps a whole bunch of classes together. And when I create applications I only add the units I really need. This is obviously key.

Mattias

An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090408/9acf670b/attachment.html

Mattias Gaertner wrote

In order to break the circles, you must first find them. Move all uses to the interface section and FPC will find them for you.

Ah, now I see what you mean... Still don't know if it's a good practice though.

Yes, that's what I meant by "unit is used or not".

Thanks Mattias for explaining...

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

That's great! Maybe it could be changed so if debug info filename is not found in debug section of executable then it tries to open a separate debug file generated by fpc (which can be of the same name as executable but different extension).

I must investigate this option.

Best regards
Boguslaw

Bogus?aw Brandys wrote

That's great! Maybe it could be changed so if debug info filename is not found in debug section of executable then it tries to open a separate debug file generated by fpc (which can be of the same name as executable but different extension)

What for? If you want a separate debug info file (-Xg) then your executable will contain a section with that file name. As result you have a small executable. If you distribute that executable without debug file it will work fine but without line info. If you distribute with debug file then you will have lineinfo. What do you need more?

Best regards,
Paul Ishenin.

How recently was this all validated to still be a problem? I know FPC didn't performed the (apparantly long due) unit system rewrite yet, but not that much problems in that realm are reported in mantis anymore, even for the current implementation.

/load/

Why are you so sure it is design, and not merely implementation?

What about this one: http://bugs.freepascal.org/view.php?id=13323

Best regards,
Paul Ishenin.

And this one: http://bugs.freepascal.org/view.php?id=13478

Best regards,
Paul Ishenin.

Wow,this is exactly what I want.Thank you.Is that really working ? I remember having problems with it - no source line info in stack trace output in case of external debug file.

Does stabs need to be loaded at program startup ? I would like it to work without need to loading debug info from this separate file at program start because this is a huge slowdown especially when antivirus is scanning file.Ideally it should load stabs only in case of exception or stack trace request.

Regards
Boguslaw

Bogus?aw Brandys wrote

Wow,this is exactly what I want.Thank you.Is that really working ? I remember having problems with it - no source line info in stack trace output in case of external debug file.

Please test yourself :) And only with fpc 2.3.1 - before it wrote full path and gdb cannot work with full path.

Best regards,
Paul Ishenin.

The only thing I know was that this only could be solved by the unit rewrite. Since it is not rewriten yet, I assume it is not fixed.

Marc

2009/4/8 Alexey S. Smirnov :

Marc Weustink (i think wrote):

Just a note: some people think that units can be compiled in one pass - this is not true. The compiler must stop on every Uses clause, and

So .exe's should be (much) smaller if your uses units are put mostly in implementation (not easy to find circular references), but we say rather put it in interface?

If we have to do multipass why is it necessary to have a distinction at all? (Ok, because writing compilers isn't exactly a walk in the park)...

Is this documented somewhere? I can't follow the logic anyway, the scope how much my code uses of another unit can not be predicted, simply by where I include the other code?

Actually, I do believe I have seen examples where code form units used in the interface was successfully smart-linked.

However there is a differentiation what can be smart linked and what not. If a class has RTTI information, then methods from it can not be removed by smart-linking. Classes with RTTI (afaik) are either included as a whole or not at all. (And that make sense, because RTTI allows to access any method by finding it from a resource or literal string; which are both not parsed by the compiler, and therefore not determinable)

Best Regards
Martin

Zitat von Reenen Laurie :

No. If yes, then you spotted a bug in the compiler and/or linker.

If we have to do multipass why is it necessary to have a distinction at all? (Ok, because writing compilers isn't exactly a walk in the park)...

1. Sometimes you need unit circles, then you need imp uses sections.
2. Some other pascal compilers provide more features than Delphi.

It is personal choice what you prefer:
Use only intf sections to avoid circles.
Use only imp sections ... oh that is not possible. Use mostly imp sections to reduce intf dependencies. For smart linking you should not create imp dependencies too, so don't use imp sections neither.

In other words:
Avoid uses sections, if this is not possible: use only intf sections. That avoids circles and improves smart linking.

Mattias

No. The location where a unit is included (interface/implementation) does not matter for smartlinking. If you really want try to drop exe size, play with the whole program optimization implemented by Jonas in trunk.

An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090408/9efeecb3/attachment.html

This could be simply the influence of a different memory layout of the exe.

An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090408/46c9ae4f/attachment.html

Afaik the rewrite had as an objective to make these errors rarer, and maybe easier to detect (just like 2.0 fixed the constantly broken optimizer).

However that doesn't necessarily means that 2.2.x (and maybe the branch based on 2.3.x if it doesn't receive the rewrite anymore) is a totally lost case. Maybe some things (like relating cross units inlines) are a lost case, but at least blatant problems should be reported.

If Lazarus as the most major user starts avoid these problems instead of reporting them, that is worrying. Paul more or less proves the point with 2 bugs in a version cycle of which one is inlining related.

No, that's not related at all.

If we have to do multipass why is it necessary to have a distinction at all?

The compiler must know where to stop pass 1 - and that place is the begin of the implementation section. When the interface section uses definitions from other units, all these units must become part of the interface uses clause, so that the compiler can compile these units before.

The distinction between interface and implementation also allows to recompile only selected units. When only the implementation section of a unit changes, it's sufficient to recompile only that unit. When the interface part changes, also all those units must be recompiled, which use that unit.

DoDi

2009/4/8 Florian Klaempfl :

smartlinking makes a massive difference for me (1M+). wpo only took another 100K off the total (blank lcl app).

henry

Marco van de Voort wrote

If Lazarus as the most major user starts avoid these problems instead of reporting them, that is worrying. Paul more or less proves the point with 2 bugs in a version cycle of which one is inlining related.

For me, when developing it is the difference between a "make" and a "make clean all" on every compilation. (and I compile a lot of times when refactoring). The first is doable, in case of the latter I quit development.

Marc

An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090409/d35b9a47/attachment.html

No, the initialization section of the graphics unit and its dependencies is used. The lesson is: you cannot smart link away initialization (and finalization) sections of a unit.

Vincent

An HTML attachment was scrubbed...
URL: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090409/d60868d7/attachment.html

Nope, that was the begin..end. in units. For dlls you're right (iirc)

Marc

Marco van de Voort wrote

If Lazarus as the most major user starts avoid these problems instead of reporting them, that is worrying. Paul more or less proves the point with 2 bugs in a version cycle of which one is inlining related.

Another known and workarounded in lazarus problem: http://bugs.freepascal.org/view.php?id=13481

Sometimes it is very difficult to avoid it.

Best regards,
Paul Ishenin.

Vincent Snijders escribi?:

Why not?

Is there are a design reason for such behavior?

I mean.
Is there a reason why a linker should never remove such sections? Or the problem is that it is too difficult and complex to implement such a smart compiler/linker?

Santiago A.

Well,they do not work with debug info placed into separate file.It is probably minor problem, I've found that .stabs and .stabstr sections are not found by function which do it flawlessly when working with original executable with debug sections.

Boguslaw

Initialization sections may be used to register things. For example if you include the interfaces unit, then you create the WidgetSet object for the chosen widgetset. No other code is in that unit, but it is needed for proper working of an LCL application (remove the interfaces unit from .lpr file to see what I mean). So it would be wrong for the compiler not to call the initialization section of that unit, even if it is not used later.

Vincent

Mattias Gaertner wrote

In order to break the circles, you must first find them. Move all uses to the interface section and FPC will find them for you.

As I already written some time ago, the solution is to introduce a hint/warning for the circular dependencies in implementation sections. This hint should probably be disabled by default, for compatibility reasons.

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090409/04b5cac9/attachment.pl

I'm not sure whether the compiler can determine circular references, without extra work.

When a circle is inevitable, the according messages must be suppressable.

When circles result from library units (LCL...), the messages are useless to the user, and

Hello all, I have converted a small Delphi project to Lazarus but I cannot get the TFloatSpinEdit decimal values to display correctly. The component shows the whole number part and no decimal part. I have set the decimal property to 6 decimal places. The value displayed by the component is either rounded up or down, however the real value is used by the program for calculations.

Using FPC 2.2.0 and Lazarus 0.9.24 with Ubuntu 8.10

Thanks Paul

Take a line like

initialization
 Register(TSomeComponent);

This means the type of some class goes into some array. However, it can be that some bit of code loads the identifier from disk and looks them up in this array, and then creates the component and streams in data from disk via RTTI. This means that already all published stuff must be linked in, and all code and fields that these use.

Similarlyo a certain percentage of virtual methods and overrides can also be reached.

It is nearly impossible for a compiler to see if this scenario is likely or not.

Can compiler detect, if initialized procedure variable is not used and smartlink it off?
In the following example:
there's a global procedure variable. it's initialized by unit2, that is used by program.
but even if it's initialized, the procedure itself (someProc) is never called. So, is it possible to cut off someProc and MyProc as well?

--- unit1.pas ---

interface
var
  someProc : TProcedure;

--- unit2.pas ----

uses
  unit1;
procedure MyProc;
initialization
  someProc := @MyProc;

--- program.pas

uses
  unit1, unit2;
begin
  writeln('hello world');
end.

thanks,
dmitry

Op woensdag 08-04-2009 om 17:14 uur [tijdzone +0100], schreef Martin Friebe:

It's not documented as it's not true. A few of the reasons for that you mentioned yourself.

Joost

In theory this could be done I think, but it is a global optimization, and is currently not yet done.

Global optimization have a lot of practical concerns though since they often require multiple compilation passes, and thus a lot of infrastructure to make it end-user ready.

Hi

Try a recent version of Lazarus.
TFloatSoinEdit was patched severla times since Laz 0.9.24

Bart

I have updated FPC to 2.2.2-8 and Lazarus to 0.9.26-4 using Ubuntu 9.04 Beta

The problem is still the same. I can type the decimal numbers into the component but as soon as the focus goes to another component the decimal part of the number disappears.

Thanks for your reply, it pushed me to update.

regards Paul

I just tried with 0.9.27 (r19310) and the GTK2 widgetset and everything works fine. What widgetset are you using and what character (based on your locale) is the decimal character? On my system the decimal character is a fullstop - in other locales it can be a comma.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Yes I have been doing more testing and it works ok up to 5 decimal places. I require 6 decimal places to correspond with the accuracy required by another program. Unfortunately I had not tried at a lower number of decimal places(silly me).

It looks like I will have to live with this resolution.

Thanks for your help, I am using GTK and a Fullstop.

Regards Paul

Paul Parkyn wrote

Yes I have been doing more testing and it works ok up to 5 decimal places. I require 6 decimal places to correspond with the accuracy required by another program. Unfortunately I had not tried at a lower number of decimal places(silly me).

I tried with only two decimals. After reading your email, I tried again. I noticed by default it truncates to 2 decimals. Then I saw the 'DecimalPlaces' property. I set it to 6 and type in 12.123456 and tabbed to another component. No problems. It remember the 6 decimals without problems.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Hello Graeme, It looks like I will have to upgrade again to 0.9.27, it is good to know that it is OK, so will persevere with it.

Regards Paul

Upgrading to 0.9.27 is not safe, it is changing every day. Graeme uses a particular revision of 0.9.27, that he found safe.

Vincent

thank you Vincent for a timely reminder.
Regards Paul.

Vincent is correct. Before I try a new version or revision of Lazarus I make a note of which revision I was using. Then update and test. If something is major wrong, I revert back to the previous revision I used.

Alternatively, you can simply back-port the fixes in TFloatSpinEdit to a 0.9.26.x version.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Hello All, I have recently upgraded my system and when trying to compile a project I get the above error.

I am using Ubuntu 9.04 which installed FPC 2.2.2-8 and Lazarus 0.9.26-4. The project was initially done under FPC 2.2.0 and Lazarus 0.9.24.

Thanks for any help

regards Paul