<div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Michael Van Canneyt via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org">fpc-pascal@lists.freepascal.org</a>> schrieb am Mo., 20. Juni 2022, 15:41:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On Mon, 20 Jun 2022, Sven Barth wrote:<br>
<br>
> Michael Van Canneyt <<a href="mailto:michael@freepascal.org" target="_blank" rel="noreferrer">michael@freepascal.org</a>> schrieb am Mo., 20. Juni 2022,<br>
> 08:04:<br>
><br>
>><br>
>><br>
>> On Mon, 20 Jun 2022, Sven Barth via fpc-pascal wrote:<br>
>><br>
>>> Am 20.06.2022 um 03:37 schrieb Hairy Pixels:<br>
>>>><br>
>>>>> On Jun 19, 2022, at 10:04 PM, Sven Barth <<a href="mailto:pascaldragon@googlemail.com" target="_blank" rel="noreferrer">pascaldragon@googlemail.com</a>><br>
>><br>
>>> wrote:<br>
>>>>><br>
>>>>> As you can see the allocation only happens once and not all the time.<br>
>>>>> What might be worse however is the optimization behavior as in this<br>
>>> example the compiler wouldn't optimize the counter variable into a<br>
>> regvar<br>
>>> with enabled optimizations (however in case of a nested function the<br>
>> compiler<br>
>>> wouldn't do this either if the function isn't inlined).<br>
>>>>><br>
>>>><br>
>>>> I’m saying if the OUTER method is in a tight loop (Foo in this example)<br>
>>> you’re in trouble because it now contains an allocation which is<br>
>> unexpected.<br>
>>><br>
>>> In that case we're in the same territory as always: ensure that you know<br>
>>> what your code does. It's the same reason why adding character by<br>
>>> character to a managed String is slower then allocating the string once<br>
>>> and then setting the characters. And I think it's very seldom that<br>
>>> someone uses a function reference that does not leave the scope of the<br>
>>> surrounding function.<br>
>><br>
>> Does this not depend on the callback declaration ?<br>
>><br>
>> Type<br>
>>    FuncRef = reference to procedure(a : integer);<br>
>><br>
>> Procedure DoSomething(f : FuncRef);<br>
>> begin<br>
>> end;<br>
>><br>
>> Procedure UseSomething;<br>
>><br>
>> begin<br>
>>    For I:=X to SomeLimit do<br>
>>      DoSomething(Whatever)<br>
>> end;<br>
>><br>
>> Does the declaration of DoSomething (which uses reference to) not<br>
>> ensure that an interface is created in UseSomething ?<br>
><br>
><br>
> Yes, in your example this is the case, but look at mine again: it's<br>
> unnecessary to create the capture object here and in theory the compiler<br>
> could convert it to an ordinary nested function variable.<br>
<br>
My point is that if someone creates an API where he/she uses <br>
"reference to procedure" then the consumer of the API is stuck <br>
with the creation of an interface.<br>
<br>
So it's not always a choice whether an interface will be used or not.<br>
<br>
My conclusion is then that 'reference to' should be used sparingly in public APIs <br>
as they are (relatively) expensive.<br>
<br>
Unless I missed/misunderstod something of course...<br></blockquote></div><div dir="auto"><br></div><div dir="auto">No, you're essentially right here. Though the passing onto the function itself is only an adjustment of the reference count and the creation of the capturer amortizes with the amount of different anonymous functions you have inside a function (the more the less is the cost per anonymous function). </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>