[fpc-devel] inline... and philosophy

[Marco van de Voort]

Op 2019-11-08 om 23:37 schreef J. Gareth Moreton:
> 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).

Did you btw read the size matters wikipedia entry? It has some hints 
about common pitfalls? (like measuring too small binaries, or pure 
winapi ones vs one with a framework behind it)

https://wiki.freepascal.org/Size_Matters

> 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.

Yes. It simply starts with the entrypoint(s) and starts marking 
reachable symbols. I tried to summarize this a bit in this post:

https://stackoverflow.com/questions/4519726/delphi-which-are-the-downsides-of-having-unused-units-listed-in-the-uses-clause/4519894#4519894

>
> 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.

Don't worry too much. Just remain constructive and it will all sort out.

>
> 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).
>
Start with asking why you feel the need to do it, and how much would be 
enough.