[fpc-devel] inline... and philosophy

J. Gareth Moreton gareth at moreton-family.com
Fri Nov 8 23:37:10 CET 2019

It is a good point.  With my C++ programs, I tend to compile with 
everything statically linked and self-contained, since it tends to be 
smaller than a dynamically-linked program plus the redistributable 
combined (and the risk of "DLL Hell" means you can't just install the 
redistributable in the System directory). Granted, it's useful if you 
are shipping a lot of small utilities together.  Admittedly, FPC might 
benefit from the dynamically-linked redistributable.  A workplace that I 
was once doing a contract for turned down my request to have FPC 
installed because there were too many EXE files to add to their 
exceptions list (the company dealt with financial data, so they were 
extra-paranoid about what gets installed on their workstations).

Does smart linking strip out elements of the RTL that aren't used?  
Granted, I'm trying to think of an example off the top of my head - I 
was going to say "WriteLn", but I can see the internal functions using 
them for stack traces and exception handling.

I do hope I'm not a person who people wish to avoid... I've gotten too 
passionate for my own good a couple of times.  I do want to learn 
everything I can when it comes to the inner workings of a binary 
(admittedly I'm currently locked to Intel platforms, but that may change 
in future).  The warning of 'blobing' as a reason against inlining 
single-use functions was never something I was introduced to or was 
really documented anywhere, so I didn't really know any better.  I'm 
still guessing what is meant by 'blobing', but hopefully I can learn 
soon enough.

Seeking to reduce binary size (without sacrificing speed) and make as 
many optimisations as possible may be a fool's errand because the 
returns don't justify the costs, but I personally enjoy the challenge 
and puzzle-solving element of it.  I just hope I haven't scared off the 
administrators when I argued with Florian on my jump optimisations (the 
aforementioned inline/blobing issue).

Gareth aka. Kit

On 08/11/2019 22:22, Nikolai Zhubr via fpc-devel wrote:
> 08.11.2019 16:28, J. Gareth Moreton:
> [...]
>> No gain? Wow, is whole-program optimisation that underperforming? Given
>> the bloated size of FPC's binaries compared to, say, what a mainstream
>> C++ compiler than do, I would have thought that there could be a lot
> Keep in mind that pretty much any tiny MSVC application would these 
> days push a (few-megabytes-sized) vcredist package in front of it. 
> Similarly, gcc would typically dynamically link against 
> some-megabytes-sized libc and other system libraries. On the other 
> hand, FPC typically produces self-contained binaries with all required 
> RTL code built-in. Whether it is good or not depends on your usage 
> context, but application binary size comparison should at least take 
> this into account to be of some use.
> -- 
> Regards,
> Nikolai
>> that could be stripped out in regards to unused functions and the like.
>> Or am I missing something?  The large binary sizes feel like an elephant
>> in the room that no-one talks about.  What causes them?
>> Gareth aka. Kit
>> _______________________________________________
>> fpc-devel maillist - fpc-devel at lists.freepascal.org
>> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

More information about the fpc-devel mailing list