Consider using final on derived (component) classes

[Kronos3]

F´ Version
Affected Component

---

Feature Description

Add final to component implementations to allow compiler to remove one layer of indirection to port calls.

Rationale

When calling a virtual function, the compiler will add an operation that checks the vtable for an override above it's own implementation. We can use final to "devirtualize" the CPP implementations at compile time.

For our use case final is perfect for our derived component classes. At the moment we are passing a virtual function pointer (input port call) to connect output -> input ports. This means that there are two levels of indirection in a port call:

1. Load the target input port call address (function pointer)
2. Check the vtable for an override (which does not exist)

Read more about it here https://llvm.org/devmtg/2016-11/Slides/Padlewski-DevirtualizationInLLVM.pdf

[LeStarch]

This makes sense to me! Our components function as final classes anyway.

[LeStarch]

At one time, this would not have been desired behavior as there was a concept of using inheritance to make similar components that derived from a common interface. However, we have converged on the concept of using FPP style interfaces as the preferred method resulting in distinct components that share the same shape.

All this is to say, from a development perspective and an F Prime/FPP assumption perspective, this is likely preferred regardless of the value performance improvement. @timcanham @bocchino do you concur?

[celskeggs]

I'll also second this request, not just because of performance, but because it helps the C++ compiler detect missing port handlers sooner. If I compile just a single component, the build can succeed even if the component is missing a handler. (I won't hit an error until I construct an instance of the component in my topology.) If we include the final keyword by default, the missing handler will be caught very quickly when compiling the component.