- binary size increase (e.g look at that : https://gcc.godbolt.org/z/xre7cp)
- more symbols (I guess you never hit the per-object file symbol limit on windows, even with /BIGOBJ - when you do the only thing left is despair).
- most callbacks will have to copy a kind of `this` pointer so the size of your objects increase and they stop fitting into cache lines
- when you have "normal" inheritance, the vtable of your parent object is generally already in your cache, while here there will be one vtable per-object (and no, the vtables aren't optimized to be part of the object itself so you still get that indirection even with SBO). so goodbye memory coherency. I've been working on my own callback implementation with an inlined vtable which allowed me to grasp sometimes more than 30% perf improvement vs std::function, in callback-heavy code : https://github.com/jcelerier/smallfunction/blob/master/small...
Coming from embedded development, the amount of short-lived heap allocations that are so conveniently swiped under the carpet with C++ is ridiculous. Even with something like slab allocators and extremely cheap allocs, there are always cases when alloc-free cycles fall on the edge of slab and become very expensive. The less is allocated during the run-time the better.
When these are combined across the whole codebase, optimizing them away _does_ result in a noticeable speed increase and makes the whole thing behave more predictably. Regardless of their perceived per-call cost.
I obviously would not be using this (or anyone else's higher level framework!) if I was targeting an embedded platform.
But the downvotes indicate the cognitive dissonance here. It’s still fashionable to hate on Electron.
Unless the profiler marks that code as reason to worry about, I wouldn't spend one second thinking about it.
(The callback approach is OOP I would say. And as always, OOP prevents us from seeing the better way to structure processing).