On Sat, 26 Oct 2019, Ben Grasset wrote:
On Sat, Oct 26, 2019 at 1:31 PM Florian Klämpfl <flor...@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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
