[fpc-devel] Question on updating FPC packages

[Michael Van Canneyt]

On Sat, 26 Oct 2019, Ben Grasset wrote:

> On Sat, Oct 26, 2019 at 1:31 PM Florian Klämpfl <florian at freepascal.org>
> wrote:
>
>> This is imo a waste of time and clutters only code. It is much more
>> beneficial to
>> improve the compiler to avoid a copying of the variable if it can prove
>> that it is not needed (or to improve auto inlining.)
>>
>
> While I absolutely agree that it would be nice if FPC auto-inlined *by
> default*, as most compilers do (*without* the {$AUTOINLINE} optimization
> directive that essentially nobody knows exists and thus never uses
> anyways), FPC doesn't do so currently, and as far as I can tell probably
> won't in the foreseeable future.

Clairvoyance is a rare gift.

>
> At risk of sounding overly abrasive or rude, there is *enormous* amounts of
> code in both the RTL and packages that is almost unusably slow due to what
> seems like a general lack of *any kind* of concern for performance.

Absolutely.

Personally, I don't have any concern for performance in this sense. Almost zero.
I invariably favour code simplicity over performance, for sake of maintenance.

For good reason: for the kind of code which I create daily, the kind of
micro-optimizations that you seem to refer to, are utterly insignificant,
and I expect the compiler to handle them. If it currently does not, then I
think the compiler, rather than the code, must be improved.

Code should not entirely disregard optimization, but then it should be on a
higher level: don't use bubble sort when you can use a better sort. No
amount of micro-optimization will make bubble sort outperform quickort.

Saying that the code is 'almost unusably slow' is the kind of statement that does
not help. I use the code almost daily in production, no complaints about
performance, so clearly it is usable.

Instead, demonstrate your claim with facts, for example by creating a patch that
demonstrably increases performance.


> Far too much of it is just un-inlined heap allocation on top of un-inlined
> heap allocation on top of un-inlined heap-allocation on top of for-loop
> that uses "Integer" when it should really use "SizeInt" on top of utter
> avoidance of pointer arithmetic even though it's always faster on top of
> methods that have no reason to be marked "virtual" but are anyways on top
> of blah blah blah... I'm sure you get the point.

These are the kind of micro-optimizations that are irrelevant for me.

About virtual:
In general, don't condemn the use virtual unless you know why it was put there.
Extensability & compatibility with delphi are 2 important reasons.

Sizeint vs. Integer. 2 points:

1. A programmer should not have to care. The programmer must care
about 'what does the logic require', not 'what does the CPU require'.
It's the job of the compiler to make sure it creates the most suitable code
for a given type.

2. The current amount of Integer types is a historical mess. Many/Most of these
types did not exist when the RTL code was written. So if today with the
whole zoo of integers we have (it's like elementary particle physics
quadrupled) there is still a lot of code that uses suboptimal integer types:
it is only to be expected. I certainly don't go over the codebase whenever a
new integer type is invented.  Can this be improved ? Certainly. Do I want
to do this ? No, I think it is more important for me to add new functionality.


> And of course I haven't even mentioned the fact that in reality, *anywhere*
> that an advanced record (or even object) can be used instead of a class, it
> should be, because it means you're avoiding an unnecessary allocation, but
> good luck convincing anyone who matters of that!

Several points here.

Most of the code was written before advanced records existed.

There is backwards and/or delphi compatibility to be considered.

Advanced records also have a disadvantage: copying them is expensive.
So when advocating this change: make sure a record is not being passed
around and/or copied a lot.

That said, I haven't seen a single proposal where you personally would
change a class to an advanced record. But maybe I missed such cases?

>
> I'm sure you get my point.

I think I do. I don't necessarily agree with all of what you say.

If you genuinely believe that micro-optimization changes can make a difference:

Submit patches. When focused and well explained, I doubt they will be refused.

When such patches appear for code that I wrote/maintain, I almost invariably
apply them. For most, I didn't even require explicit proof that they improve speed. 
It's not because I don't care about optimization that I deny
someone else the right to care and to submit patches.

Michael.