4 ms·

Oh ffs, have you actually calculated this "cost" on a CPU made after 1985?

by antoinevg 7y ago

eps 7y ago
Welcome to the Kingdom of Electron, where RAM is aplenty and CPU cycles are puny noise down the line.
- projektfu 7y ago
  You're looking in the wrong place for performance improvements. These are not the inner loop. They're not even the outer loop.
  - eps 7y ago
    These can be in fast path, depends on the code, but that's not the point. 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.
    - antoinevg 7y ago
      To contextualise, my comment absolutely assumed a modern desktop target. I obviously would not be using this (or anyone else's higher level framework!) if I was targeting an embedded platform.
- frutiger 7y ago
  Chromium is to blame not Electron. Electron is “just” Chromium + Node.
  - 0815test 7y ago
    Web and ECMAscript standards are to blame not Chromium. Chromium and Node are "just" implementation work, it's not like Firefox is that much better either!
    - frutiger 7y ago
      Ha, I totally agree. Actually if we’re being honest, it’s the programmers that are to blame. But the downvotes indicate the cognitive dissonance here. It’s still fashionable to hate on Electron.
jcelerier 7y ago
There's a lot of costs which all sum up: - binary size increase (e.g look at that : https://gcc.godbolt.org/z/xre7cp 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/smallfun/include/smallfun.hpp#L29 https://github.com/jcelerier/smallfunction/blob/master/small...

Oh ffs, have you actually calculated this "cost" on a CPU made after 1985?

eps 7y ago

Welcome to the Kingdom of Electron, where RAM is aplenty and CPU cycles are puny noise down the line.

projektfu 7y ago
You're looking in the wrong place for performance improvements. These are not the inner loop. They're not even the outer loop.
- eps 7y ago
  These can be in fast path, depends on the code, but that's not the point. 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.
  - antoinevg 7y ago
    To contextualise, my comment absolutely assumed a modern desktop target. I obviously would not be using this (or anyone else's higher level framework!) if I was targeting an embedded platform.
frutiger 7y ago
Chromium is to blame not Electron. Electron is “just” Chromium + Node.
- 0815test 7y ago
  Web and ECMAscript standards are to blame not Chromium. Chromium and Node are "just" implementation work, it's not like Firefox is that much better either!
  - frutiger 7y ago
    Ha, I totally agree. Actually if we’re being honest, it’s the programmers that are to blame. But the downvotes indicate the cognitive dissonance here. It’s still fashionable to hate on Electron.

jcelerier 7y ago

There's a lot of costs which all sum up: - binary size increase (e.g look at that : https://gcc.godbolt.org/z/xre7cp 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/smallfun/include/smallfun.hpp#L29 https://github.com/jcelerier/smallfunction/blob/master/small...