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@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
