<div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Jonas Maebe via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org">fpc-pascal@lists.freepascal.org</a>> schrieb am So., 5. Juni 2022, 21:02:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2022-06-05 18:20, Anthony Walter via fpc-pascal wrote:<br>
<br>
> As the "reference to" feature was recently added to fpc trunk, I'd like <br>
> to ask if internally there are any penalties (performance perhaps) or <br>
> drawbacks to using them in place of the more traditional "procedure" <br>
> and "procedure of object" types?<br>
<br>
The downside is that a "reference to" always gets wrapped in a <br>
reference-counted interface, and hence is much more expensive than a <br>
place procedural variable ("of object" or not).<br></blockquote></div><div dir="auto"><br></div><div dir="auto">As I can see neither Anthony's nor Ryan's mail, but I can see them in the archive, I'll use Jonas mail for some general replies (please CC me when replying):</div><div dir="auto"><br></div><div dir="auto">A function reference is *always* an interface. That's why I wrote in my announcement that it really does behave like an interface including inheritance and all that. So once you have a function reference there isn't much you can do (let's ignore some small possibilities through inlining). What *might* be done however is that for cases where no state is required the compiler could simply fake an interface (using some static methods to provide _AddRef, _Release and _QueryInterface that essentially do nothing and then the converted method providing the Invoke method). This would be more lightweight for specific use cases. But before implementing something like that I want to be sure that the feature as it should be works correctly (which it still doesn't with some optimizations enabled). </div><div dir="auto"><br></div><div dir="auto">Also regarding the idea of using a variant record: you can't have a managed type in a variant record, because the compiler would not be able to know whether to touch the reference count or not. This would mean that you'd need an additional field to keep track of the type and helper methods and/or code that then handles and calls it correctly. Thus any advantage of avoiding an indirect call through the interface's VMT goes out the window again, not to mention potential branch predictor issues. </div><div dir="auto"><br></div><div dir="auto">Also keep in mind that the expensive creation only happens once. Afterwards it's "only" the price of an indirect call. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div class="gmail_quote" dir="auto"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div>