On Mon, 20 Jun 2022, Sven Barth wrote:
Michael Van Canneyt <mich...@freepascal.org> schrieb am Mo., 20. Juni 2022,
08:04:
On Mon, 20 Jun 2022, Sven Barth via fpc-pascal wrote:
Am 20.06.2022 um 03:37 schrieb Hairy Pixels:
On Jun 19, 2022, at 10:04 PM, Sven Barth <pascaldra...@googlemail.com>
wrote:
As you can see the allocation only happens once and not all the time.
What might be worse however is the optimization behavior as in this
example the compiler wouldn't optimize the counter variable into a
regvar
with enabled optimizations (however in case of a nested function the
compiler
wouldn't do this either if the function isn't inlined).
I’m saying if the OUTER method is in a tight loop (Foo in this example)
you’re in trouble because it now contains an allocation which is
unexpected.
In that case we're in the same territory as always: ensure that you know
what your code does. It's the same reason why adding character by
character to a managed String is slower then allocating the string once
and then setting the characters. And I think it's very seldom that
someone uses a function reference that does not leave the scope of the
surrounding function.
Does this not depend on the callback declaration ?
Type
FuncRef = reference to procedure(a : integer);
Procedure DoSomething(f : FuncRef);
begin
end;
Procedure UseSomething;
begin
For I:=X to SomeLimit do
DoSomething(Whatever)
end;
Does the declaration of DoSomething (which uses reference to) not
ensure that an interface is created in UseSomething ?
Yes, in your example this is the case, but look at mine again: it's
unnecessary to create the capture object here and in theory the compiler
could convert it to an ordinary nested function variable.
My point is that if someone creates an API where he/she uses
"reference to procedure" then the consumer of the API is stuck
with the creation of an interface.
So it's not always a choice whether an interface will be used or not.
My conclusion is then that 'reference to' should be used sparingly in public APIs
as they are (relatively) expensive.
Unless I missed/misunderstod something of course...
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
