3 ms·

All abstractions are pure overhead. Let's code everything by hand by flipping bits in memory using a tiny magnetic needle.

miohtama 4y ago
This is not correct. Zero cost abstractions are not overhead. Some abstractions are zero cost abstractions. Thus, not all abstractions are pure overhead. More on zero cost abstractions here: https://stackoverflow.com/a/69178445/315168 https://stackoverflow.com/a/69178445/315168
- mixedCase 4y ago
  > Thus, all abstractions are not pure overhead Sorry for the pedantry, but I believe this would still be wrong as phrased. Maybe "not all abstractions are pure overhead" would work?
- asveikau 4y ago
  The Stroustrup quote in that thread is better than what you linked to. The concept was popularized by C++ templates. The idea is that the templated code would be just as good as if you hand wrote it without generics. There's no extra function pointers or virtual calls, extra indirection by pointing to some user data, etc.; the tree node or whatever and data struct are declared as a single entity, there's no runtime callbacks, etc.
- _Algernon_ 4y ago
  I thought the second half would make it clear that I'm being sarcastic but clearly I'm wrong. Pendants gonna pedant I guess.
acdha 4y ago
This is over-simplified: the overhead of an abstraction can be cancelled out by work or optimizations which you wouldn't have done without the abstraction. As a simple example, most Python programs are faster than the C code the same developer would have written in the same time because they have a rich library of optimized code and getting it working quickly means that they had more time to focus on algorithm-level improvements. That of course doesn't mean that a C programmer can't beat it in performance but once you're past very simple examples those abstractions are harder to beat than they might seem — I've seen multiple cases where someone thought they could do that and wasted days (or in one case, months) only to eke out less than a 10% improvement. In this case, React is slow and memory hungry because when you make a change you go through this process: 1. Update some value 2. … triggering updates to the virtual DOM 3. … requiring it to caluclate the difference between the real DOM and the virtual DOM 4. … and finally apply the changes to the real DOM That abstraction requires substantial extra state to be stored and managed. If you have a different abstraction which directly manages the DOM, you can avoid steps 2 and 3. The big question is a) does your code do enough manipulation for this to be noticeable? (React is less slow than it used to be but I've seen 4 order of magnitude deltas in optimized React code so it's not uncommon to see it chug with large pages, especially on older hardware like a lot of the public uses) and b) does that other abstraction have drawbacks for your developers which cost you more than the performance savings?
- _Algernon_ 4y ago
  Tough crowd today... My comment was a reference to xkcd: https://xkcd.com/378/ https://xkcd.com/378/ Maybe I should have made it more obvious by referencing the butterflies instead.
  - acdha 4y ago
    Heh, yes. This runs into something like Poe’s law because you can find people who sound exactly like that but are serious. I especially remember someone’s reaction when their hand-tuned assembly started under-performing compared to GCC once we recompiled for (IIRC) Pentium 4 chips.

miohtama 4y ago

This is not correct. Zero cost abstractions are not overhead. Some abstractions are zero cost abstractions. Thus, not all abstractions are pure overhead. More on zero cost abstractions here: https://stackoverflow.com/a/69178445/315168 https://stackoverflow.com/a/69178445/315168

mixedCase 4y ago
> Thus, all abstractions are not pure overhead Sorry for the pedantry, but I believe this would still be wrong as phrased. Maybe "not all abstractions are pure overhead" would work?
asveikau 4y ago
The Stroustrup quote in that thread is better than what you linked to. The concept was popularized by C++ templates. The idea is that the templated code would be just as good as if you hand wrote it without generics. There's no extra function pointers or virtual calls, extra indirection by pointing to some user data, etc.; the tree node or whatever and data struct are declared as a single entity, there's no runtime callbacks, etc.
_Algernon_ 4y ago
I thought the second half would make it clear that I'm being sarcastic but clearly I'm wrong. Pendants gonna pedant I guess.

acdha 4y ago

This is over-simplified: the overhead of an abstraction can be cancelled out by work or optimizations which you wouldn't have done without the abstraction. As a simple example, most Python programs are faster than the C code the same developer would have written in the same time because they have a rich library of optimized code and getting it working quickly means that they had more time to focus on algorithm-level improvements. That of course doesn't mean that a C programmer can't beat it in performance but once you're past very simple examples those abstractions are harder to beat than they might seem — I've seen multiple cases where someone thought they could do that and wasted days (or in one case, months) only to eke out less than a 10% improvement. In this case, React is slow and memory hungry because when you make a change you go through this process: 1. Update some value 2. … triggering updates to the virtual DOM 3. … requiring it to caluclate the difference between the real DOM and the virtual DOM 4. … and finally apply the changes to the real DOM That abstraction requires substantial extra state to be stored and managed. If you have a different abstraction which directly manages the DOM, you can avoid steps 2 and 3. The big question is a) does your code do enough manipulation for this to be noticeable? (React is less slow than it used to be but I've seen 4 order of magnitude deltas in optimized React code so it's not uncommon to see it chug with large pages, especially on older hardware like a lot of the public uses) and b) does that other abstraction have drawbacks for your developers which cost you more than the performance savings?

_Algernon_ 4y ago
Tough crowd today... My comment was a reference to xkcd: https://xkcd.com/378/ https://xkcd.com/378/ Maybe I should have made it more obvious by referencing the butterflies instead.
- acdha 4y ago
  Heh, yes. This runs into something like Poe’s law because you can find people who sound exactly like that but are serious. I especially remember someone’s reaction when their hand-tuned assembly started under-performing compared to GCC once we recompiled for (IIRC) Pentium 4 chips.