5 ms·

This can be described more simply as: Running native code vs. abstracted code. Abstracted code is bloody slow by its very nature, but devs of the 21st century

This can be described more simply as: Running native code vs. abstracted code. Abstracted code is bloody slow by its very nature, but devs of the 21st century love abstraction so we get software that run like drunk walruses on 16-core processors with hundreds of gigabytes of RAM.

wonnage 4y ago
native vs abstracted is not a thing
gmueckl 4y ago
That's not what I was going for. Any new feature you add to a code path will add new instructions that the CPU will have to execute, even if it is just the check to see whether that feature is enabled. Do that a few hundred or a few thousand times and a previously fast code path will have its performance degraded. This is the unavoidable tax of feature creep.
- foobazgt 4y ago
  Feature creep definitely bloats and slows software in meaningful ways, but it's not via checking feature flags. In the worst case, a feature test would be a cache miss, requiring a read from main memory. That's somewhere in the ballpark of 50ns. So, you could test 1000 different flags, every single one being a cache miss, and you'd still be 100x faster than what humans can generally perceive. In reality, almost all of those reads will be cache hits unless you're doing something pathalogical, so you're probably talking on the order of 100ns for the whole lot.
  - gmueckl 4y ago
    How many of these do you do once per document, once per input token in the lexer, once per token in the parser, once per DOM node, once per CSS rule...? It's not always a one time cost.
    - foobazgt 4y ago
      If you're executing 10M flag tests per document, something has gone very horribly awry. If you discover production code that is doing this, send the maintainers a PR.
asveikau 4y ago
No, I think it's possible to get the abstraction right. There are probably UI toolkits running an abstraction that you don't notice in the same way. For example wxwidgets apps do tend to feel non native on some platforms (especially Mac), but they're not slow. I remember GTK+ when it used to run on Windows about 20 years ago wasn't terrible. I think OpenStep on NT was pretty good -- iTunes on Windows seemed to be doing a similar thing, too. It's the wrong abstraction that makes it suffer.
_0w8t 4y ago
Native code can use a wrong abstraction as well. Around 1996 I tested on Linux a Java app that rendered everything in Java using IFC from Netscape. The speed of its UI was on pair with a native app using Motif toolkit despite the usage of images.
soraminazuki 4y ago
Native vs. abstracted is hardly an effective indicator for analyzing performance. There are many abstractions that improves performance, a prime example being caches. Even abstractions that can introduce some overhead can improve performance under certain conditions, like virtual memory. The dichotomy is also too vague a concept to be anywhere useful as a proxy for performance. This very thread is a good example. I don't see how XUL is more "native" than HTML is, but some see otherwise. The only reliable way to reason about performance is to look at what the code is actually doing.

wonnage 4y ago

native vs abstracted is not a thing

gmueckl 4y ago

That's not what I was going for. Any new feature you add to a code path will add new instructions that the CPU will have to execute, even if it is just the check to see whether that feature is enabled. Do that a few hundred or a few thousand times and a previously fast code path will have its performance degraded. This is the unavoidable tax of feature creep.

foobazgt 4y ago
Feature creep definitely bloats and slows software in meaningful ways, but it's not via checking feature flags. In the worst case, a feature test would be a cache miss, requiring a read from main memory. That's somewhere in the ballpark of 50ns. So, you could test 1000 different flags, every single one being a cache miss, and you'd still be 100x faster than what humans can generally perceive. In reality, almost all of those reads will be cache hits unless you're doing something pathalogical, so you're probably talking on the order of 100ns for the whole lot.
- gmueckl 4y ago
  How many of these do you do once per document, once per input token in the lexer, once per token in the parser, once per DOM node, once per CSS rule...? It's not always a one time cost.
  - foobazgt 4y ago
    If you're executing 10M flag tests per document, something has gone very horribly awry. If you discover production code that is doing this, send the maintainers a PR.

asveikau 4y ago

No, I think it's possible to get the abstraction right. There are probably UI toolkits running an abstraction that you don't notice in the same way. For example wxwidgets apps do tend to feel non native on some platforms (especially Mac), but they're not slow. I remember GTK+ when it used to run on Windows about 20 years ago wasn't terrible. I think OpenStep on NT was pretty good -- iTunes on Windows seemed to be doing a similar thing, too. It's the wrong abstraction that makes it suffer.

_0w8t 4y ago

Native code can use a wrong abstraction as well. Around 1996 I tested on Linux a Java app that rendered everything in Java using IFC from Netscape. The speed of its UI was on pair with a native app using Motif toolkit despite the usage of images.

soraminazuki 4y ago

Native vs. abstracted is hardly an effective indicator for analyzing performance. There are many abstractions that improves performance, a prime example being caches. Even abstractions that can introduce some overhead can improve performance under certain conditions, like virtual memory. The dichotomy is also too vague a concept to be anywhere useful as a proxy for performance. This very thread is a good example. I don't see how XUL is more "native" than HTML is, but some see otherwise. The only reliable way to reason about performance is to look at what the code is actually doing.