<div dir="ltr"><div dir="ltr">On Sun, Oct 27, 2019 at 5:27 AM Michael Van Canneyt <<a href="mailto:michael@freepascal.org">michael@freepascal.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Saying that the code is 'almost unusably slow' is the kind of statement that does<br>
not help. I use the code almost daily in production, no complaints about<br>
performance, so clearly it is usable.<br>
<br>
Instead, demonstrate your claim with facts, for example by creating a patch that<br>
demonstrably increases performance.<br></blockquote><div><br></div><div>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.</div><div><div class="gmail_quote"><div><br></div><div><div dir="ltr">On Sun, Oct 27, 2019 at 5:27 AM Michael Van Canneyt <<a href="mailto:michael@freepascal.org">michael@freepascal.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If you genuinely believe that micro-optimization changes can make a difference:<br>
<br>
Submit patches. When focused and well explained, I doubt they will be refused.<br></blockquote><div><br></div><div>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.</div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 27, 2019 at 5:46 AM Florian Klämpfl <<a href="mailto:florian@freepascal.org">florian@freepascal.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Another point: for example <br>
explicit inline increases normally code size (not always but often)</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div></div></div></div></div></div></div></div></div>