On Sun, Oct 27, 2019 at 5:27 AM Michael Van Canneyt <mich...@freepascal.org>

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

I was perhaps slightly exaggerating there. I use it as well in real life,
but in many cases have found myself altering the sources to perform more
optimally (some of which I could submit as patches, I suppose.

On Sun, Oct 27, 2019 at 5:27 AM Michael Van Canneyt <mich...@freepascal.org>

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

The stuff that I'm particularly concerned about is usually more along the
lines of "small things that add up in significant ways in the context of
long-running programs", so while they might be "micro" on their own I
wouldn't necessarily call them that in context of larger overall situations.

On Sun, Oct 27, 2019 at 5:46 AM Florian Klämpfl <flor...@freepascal.org>

> Another point: for example
> explicit inline increases normally code size (not always but often)

I've had the opposite experience in most cases. The code FPC generates for
something like four un-inlined functions in a situation where each one
calls the next is generally significantly bigger due to the setup for the
parameters being passed in / etc. Whereas if it's inlining all of them it
seems to be able to do a much better job of combining "redundant" things
and optimizing based on that, which tends to give a much smaller result.

Again, in a world where robust autoinlining was the default I'd happily
rely on it exclusively, as it's not as though I specifically *want* to have
to add the "inline" modifier in particular places.
fpc-devel maillist  -  fpc-devel@lists.freepascal.org

Reply via email to