DanRStevens
commented
2 years ago One area of concern I wanted to mention regarding the use of std::function, is there are some reports of performance issues with std::function, as compared to using lambas with templated methods. In particular, it adds a virtual function call, and may result in allocation of external memory when storing certain large functions, such as lambdas with a large capture group. These are not likely to be of any concern to our particular use case. In particular, for user input handlers, the tiny amount of overhead is never going to matter. Nevertheless, it might be good to better understand the situation by learning how std::function works.
First off, the performance comparison was relating std::function to template methods taking a lambda, which could inline the lambda call when instantiating the template method. The current implementation of Delegate doesn't do that. It uses pointers internally, and so it's already very similar to the virtual function call dispatch offered by std::function. The main concern then is the potential allocation of external memory.
Second, the potential use of external memory is because std::function takes ownership of the function it holds, and it can hold arbitrarily large functors, such as lambdas with large capture groups. The current implementation of Delegate doesn't provide for capturing anything beyond the this pointer, and a member function pointer, so we effectively already limit capture group size. Further, std::function offers a SBO (Small Buffer Optimization), which is generally sufficient to store such references without allocating external memory. Effectively, the only cases where std::function should need to allocate, are cases not currently supported by the Delegate code.
According to the C++ standard, the std::function object will not allocate external memory when used to store two particular small cases:
- a function pointer
- a
std::reference_wrapperto a callable object
Notably absent is a pointer to a member function. This is relevant, as all our current uses are pretty similar to calling std::bind on a this pointer with a member function pointer. As can be demonstrated, using std::bind to group a this pointer with a member function pointer does generally produce a functor that is too large to store in a std::function without externally allocated memory. However, the solution to that is simply to use a lambda rather than std::bind, as the lambda generally does fit without the SBO constraints offered by std::function.
Example:
#include <iostream>
#include <functional>
struct Object{
void method() {}
};
int main() {
Object object;
const auto func1 = std::bind(&Object::method, &object);
const auto func2 = [&object]{ object.method(); };
std::cout << sizeof(func1) << std::endl; // 24 - (64-bit g++)
std::cout << sizeof(func2) << std::endl; // 8 - (64-bit g++)
std::function<void()> callback;
callback = func1; // external allocation
callback = func2; // no external allocation
}The reason for the difference in size is the lambda stores only a single pointer to object, where as the std::bind call produces an object with a pointer to object, and a somewhat large member function pointer, which consists of a function pointer and an offset value for the this pointer. For the lambda, that member function pointer and this adjustment is effectively compiled into a thunk when the compiler generates code for the lambda's operator(), and so become part of the code rather than extra data fields.
As for verifying the lambda can be stored without extra memory allocation, that can be done with valgrind, or with other test code, such as is presented in one of the ansers to this StackOverflow question:
Avoid memory allocation with std::function and member function
In summary, std::function can replace all our current uses of Delegate with no loss of efficiency, plus support other new uses of lambdas, which may (or may not) incur a slight overhead over the existing code if they are actually used (and only when they are used).
Our
Delegatecode is super old. We should consider updating it.The
Delegatecode has a lot of macro#ifto support really old compilers. Our code relies on C++17, and perhaps soon, C++20. That means we need a reasonably modern compiler. We could gut many of the#ifchecks for old compiler support from theDelegatecode.Our custom
Delegateimplementation is from about 2005. Source: https://www.codeproject.com/Articles/11015/The-Impossibly-Fast-C-DelegatesThe current implementation far predates the C++11 standard, which introduced
std::function. It seemsstd::functionreplaces the need to write a customDelegateclass. Maybe we should update to usingstd::functionand get rid of the customDelegateclass.Our current implementation of
DelegateandSignalonly really supports member function pointers. We should add lambda support when callingSignal::connectandSignal::disconnect.It may be possible to inline the lambda. Here's how lambdas would compare to the existing way:
If we move to
std::function, it may make sense to use lambdas as the primary means of representingDelegate. That might mean using it as the primary storage type internally, or perhaps updating calls to prefer passing lambdas.