Everything here is bad and wrong on so many levels. It's hard to even wrap my head around the amount of wrong going on everywhere here.
The initial Object Oriented (OO) code - as partially demonstrated by the author, and more succinctly by the grand-author - is badly designed. In the grand-author's slides they remove a number of these stupidities, which the author appears to ignore (both for final performance comparisons and for understanding why they were even there). Notably they (the grand author) originally built a reflection (runtime type) system [0] directly into their game objects (application level code). This of course means they then ended up fighting their programming language over the performance of this as they attempted to use and improve it.
The author's improved code is also a total failure. He removes a significant amount of the flexibility in the original system, which was a requirement of the problem space. By removing features he gains a significant amount of performance (in actuality about 2x - not 10x - compared to the grand author's slides). The lack of understanding why those features were there in the first place demonstrates he doesn't understand the actual design space of the toy demonstration code. It also demonstrates he failed to read the grand-author's slides where they go through some of these changes and why they aren't viable.
The author also fails to even discuss the Entity Component System (ECS) which it should be noted is still faster (and feature intact!) than the author's code. I cannot be more emphatic on that point, an ECS is a solution to the performance of run-time composition problems, and it still worked even better than an attempt to do the OO solution right (again by removing features!).
Though the author makes an excellent point about how most ECS solutions tend to fight the programming system they are in, he doesn't really explain or demonstrate it. What the grand-author did wrong here (though probably actually not in their talk considering who they work for) is not point out that the ECS should be part of one's programming tool to be most effective. Notably the ECS optimization should be part of one's programming language [1] (a game engine's programming language - like Unity's - would count).
Point is this author is very wrong and does not understand design (in general) nor the entity component system pattern in specific at all. The grand author's example code base is disingenuous of actual OO principles, and does not provide reasonable advice on how to deploy an ECS. Oh and they both got wrong that ECS solutions should be part of one's programming tool, not application space.
[0] Engines are often attempting to solve a sufficiently complex problem space that they require runtime type systems. This is not something one can avoid unless writing a bespoke "engine" for a single game.
[1] Unless your programming language is sufficiently advanced to allow creating - effectively - compiled code at runtime as a generalized library. Which C++ is because of template meta-programming, but the included example code is not.
I think the C++ library https://github.com/skypjack/entt gets pretty close to the ideal for a purely compile time implementation. It is implemented with modern C++ template meta-programming - which is to say it is basically a DSL encoded into C++ and can generate arbitrary code at compile time - while better than it used to be to read C++ template meta-programming is still very difficult to read. It also comes with a number of utility libraries for using it efficiently and correctly, including a signal library, service locator, and scheduler (among others).
It still has it's limitations though. Because it is a compile time library, it can't do any runtime optimizations like it could with a JIT. Also, because C++ reflection is atrocious, it doesn't provide the best support for runtime type manipulation (reflection features are often paired with the component pattern implementation, especially in general purpose game engines). This comes back to dynamically meta-programmed languages (e.g. python, lisp) that could theoretically out perform even ENTT using a JIT - with the appropriate reflection features - and meta-programming. However an ECS only really makes sense in a non-garbage collected language (or if the language exposes a non-GC meta-programming interface). Since there aren't really any viable JIT (+ reflection) + meta-programmed + non-GC languages out there, I don't think a perfectly correct implementation exists.
I think an ideally implemented example will eventually be Johnathan Blow's experimental language Jai (or a library for it) given what has been stated publicly about it (metaprogramming, JITted, reflection, not garbage collected, has built in support for SoA types). But that's not a viable example to look at at the moment.
The fact the the original code is a straw-man is discussed. The fact the flexibility is being removed is discussed too, along with why it was there and hits on better ways to re-achieve it later. It's mentioned that these were going to be covered in a follow-up.
You need to work on your speed reading skills before throwing shade...
> The fact the the original code is a straw-man is discussed.
Yes, but instead of timing it against the improvements the grand-author made to the straw man, you still timed it against his straw man.
So I'll quote you: "You need to work on your speed reading skills before throwing shade..."
> The fact the flexibility is being removed is discussed too
You state: "Why do these frameworks exist then? Well to be fair, they enable dynamic, runtime composition. Instead of GameObject types being hard-coded, they can be loaded from data files. This is great to allow game/level designers to create their own kinds of objects... However, in most game projects, you have a very small number of designers on a project and a literal army of programmers, so I would argue it's not a key feature."
Which is failing to recognize that the whole point of the original code - written by a game engine developer - is to demonstrate exactly how to do this for performance and flexibility for any small team.
> along with why it was there and hits on better ways to re-achieve it later. It's mentioned that these were going to be covered in a follow-up.
With out it being there, I cannot judge it. But considering that you removed features and barely managed to match the ECS for performance is... not promising.
The point of the ECS is to be a very efficient solution to the run-time composition problem. You removed run-time composition and still weren't technically able to be more performant than it with your solution. You are comparing apples to oranges and still loosing on arguably the most key aspect of the entire problem space!
Welcome to HN! (I'm a moderator here.) Please stick to civil, substantive comments, regardless of how wrong someone else is (or you feel they are). Swipes like "calm your titties" (or even telling people to "work on their reading skills", as you did upthread) are the sort of thing we ban accounts for. We're trying hard to prevent this place from sinking into a toxic swamp, as so much of the internet has become. Doom is probably inevitable in the long run, but we're still hoping to stave it off for a while.
The initial Object Oriented (OO) code - as partially demonstrated by the author, and more succinctly by the grand-author - is badly designed. In the grand-author's slides they remove a number of these stupidities, which the author appears to ignore (both for final performance comparisons and for understanding why they were even there). Notably they (the grand author) originally built a reflection (runtime type) system [0] directly into their game objects (application level code). This of course means they then ended up fighting their programming language over the performance of this as they attempted to use and improve it.
The author's improved code is also a total failure. He removes a significant amount of the flexibility in the original system, which was a requirement of the problem space. By removing features he gains a significant amount of performance (in actuality about 2x - not 10x - compared to the grand author's slides). The lack of understanding why those features were there in the first place demonstrates he doesn't understand the actual design space of the toy demonstration code. It also demonstrates he failed to read the grand-author's slides where they go through some of these changes and why they aren't viable.
The author also fails to even discuss the Entity Component System (ECS) which it should be noted is still faster (and feature intact!) than the author's code. I cannot be more emphatic on that point, an ECS is a solution to the performance of run-time composition problems, and it still worked even better than an attempt to do the OO solution right (again by removing features!).
Though the author makes an excellent point about how most ECS solutions tend to fight the programming system they are in, he doesn't really explain or demonstrate it. What the grand-author did wrong here (though probably actually not in their talk considering who they work for) is not point out that the ECS should be part of one's programming tool to be most effective. Notably the ECS optimization should be part of one's programming language [1] (a game engine's programming language - like Unity's - would count).
Point is this author is very wrong and does not understand design (in general) nor the entity component system pattern in specific at all. The grand author's example code base is disingenuous of actual OO principles, and does not provide reasonable advice on how to deploy an ECS. Oh and they both got wrong that ECS solutions should be part of one's programming tool, not application space.
[0] Engines are often attempting to solve a sufficiently complex problem space that they require runtime type systems. This is not something one can avoid unless writing a bespoke "engine" for a single game.
[1] Unless your programming language is sufficiently advanced to allow creating - effectively - compiled code at runtime as a generalized library. Which C++ is because of template meta-programming, but the included example code is not.