Mailing lists / fpc-pascal / 2021-04
Minimal size of compiled library (DLL under Windows)
7 messages · 4 people · –
- LacaK 3
- Jonas Maebe 2
- Marco van de Voort 1
- Sven Barth 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Op 2021-04-03 om 13:22 schreef LacaK via fpc-pascal:
Show quoted text 6 lines
I am guessing, that there must be something in initialization sections
of units (SysUtils and Classes), which cause that some code is
included, right?
Can I somehow to avoid this grow of size (for example I need from
Classes only TFPList)?
Not in an easy way at the moment, I don't expect it to change anytime soon.
The problem is probably the streaming system that the compiler can't easily determine if it is used runtime. This also has resourcestrings as errors, uses typeinfo etc etc. I also see interface related support probably because tcomponent also implements interfaces.
LacaK via fpc-pascal schrieb am Sa., 3.
Apr. 2021, 13:22:
Show quoted text 21 lines
Hi,
I did small test project for library:
(with -CX -WR -O3 -Xs -XX options set)
library library1;
{$mode objfpc}{$H+}
uses
SysUtils, Classes;
begin
end.
Compilation produces DLL with size 200+ KB.
When in uses is only SysUtils then size is under 100 KB.
Whene there are not units in uses clause then size is under 40 K B.
I am guessing, that there must be something in initialization sections of
units (SysUtils and Classes), which cause that some code is included, right?
Can I somehow to avoid this grow of size (for example I need from Classes
only TFPList)?
Everything that is touched by initialization or finalization sections, even if nothing else is used, will be included.
Regards,
Sven
Op 2021-04-03 om 13:22 schreef LacaK via fpc-pascal: Not in an easy way at the moment, I…
Show quoted text 15 lines
>
> I am guessing, that there must be something in initialization
> sections of units (SysUtils and Classes), which cause that some code
> is included, right?
> Can I somehow to avoid this grow of size (for example I need from
> Classes only TFPList)?
Not in an easy way at the moment, I don't expect it to change anytime
soon.
The problem is probably the streaming system that the compiler can't
easily determine if it is used runtime. This also has resourcestrings
as errors, uses typeinfo etc etc. I also see interface related
support probably because tcomponent also implements interfaces.
What I can say is, that in initialization sections are touched:
SysUtils: WidestringManager, Exceptions, FormatSettings Classes: TCriticalSection, TList, TThreadList, TComponent (IUnknown,IDispatch, RegisterInitComponentHandler() -> var InitHandlerList), Interface (var GlobalNameSpace: IReadWriteSync)
So we see that classes like TComponent and also interfaces are touched, but they are used only in conjuction with initilizing some global variables like InitHandlerList, GlobalNameSpace.
But these variables are never used in my library. Only again in finalization sections of above mentioned units.
Does it means, that smart-linking can not remove this code due to usage of this global variables in finalization section (resp. initialization sections)?
Probably it is too hard task for linker to determine which code is realy not needed ... WPO in this regard can not help?
-Laco.
LacaK wrote 6 lines
So we see that classes like TComponent and also interfaces are touched,
but they are used only in conjuction with initilizing some global
variables like InitHandlerList, GlobalNameSpace.
But these variables are never used in my library. Only again in
finalization sections of above mentioned units.
They are used in your library as far as the linker is concerned, because the init and finalisation sections are code like any other code.
Does it means, that smart-linking can not remove this code due to usage of this global variables in finalization section (resp. initialization sections)?
Indeed.
Probably it is too hard task for linker to determine which code is realy not needed ... WPO in this regard can not help?
No. There is no way for WPO to know what side effects the initialisation of those variables could have.
Jonas
May be, that important word is here "referenced" code. Once some code (procedure, class) is referenced then this code is linked / included.
It does not play role if it is really required by program / library ... right?
L.
Show quoted text 24 lines
> So we see that classes like TComponent and also interfaces are touched,
> but they are used only in conjuction with initilizing some global
> variables like InitHandlerList, GlobalNameSpace.
>
> But these variables are never used in my library. Only again in
> finalization sections of above mentioned units.
They are used in your library as far as the linker is concerned, because
the init and finalisation sections are code like any other code.
> Does it means, that smart-linking can not remove this code due to usage
> of this global variables in finalization section (resp. initialization
> sections)?
Indeed.
> Probably it is too hard task for linker to determine which code is realy
> not needed ... WPO in this regard can not help?
No. There is no way for WPO to know what side effects the initialisation
of those variables could have.
Jonas
_______________________________________________
fpc-pascal maillist -
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
LacaK wrote 5 lines
May be, that important word is here "referenced" code.
Once some code (procedure, class) is referenced then this code is
linked / included.
It does not play role if it is really required by program / library ...
right?
It is impossible for a linker to know whether code is "really required". It doesn't know what code does. It only knows whether or not it (theoretically) can get executed.
Jonas