[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
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.
>> 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
> fpc-devel maillist - fpc-devel at lists.freepascal.org
More information about the fpc-devel