[fpc-pascal] Are there any drawbacks to "reference to"?

[Sven Barth]

Jonas Maebe via fpc-pascal <fpc-pascal at lists.freepascal.org> schrieb am
So., 5. Juni 2022, 21:02:

> On 2022-06-05 18:20, Anthony Walter via fpc-pascal wrote:
>
> > As the "reference to" feature was recently added to fpc trunk, I'd like
> > to ask if internally there are any penalties (performance perhaps) or
> > drawbacks to using them in place of the more traditional "procedure"
> > and "procedure of object" types?
>
> The downside is that a "reference to" always gets wrapped in a
> reference-counted interface, and hence is much more expensive than a
> place procedural variable ("of object" or not).
>

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):

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

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.

Also keep in mind that the expensive creation only happens once. Afterwards
it's "only" the price of an indirect call.

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20220619/3b949021/attachment.htm>