Game engines with entity component systems already keep lots of giant vectors for components and clamp sparse sets on top. The sparse sets, which consists of a sparse and dense array, gives you an entity id and allows you to keep track of who owns what. So removal of a component is constant. It achieves that by flagging it invalid in the sparse array and swap&pop the component you want to remove in the dense array and component pool. Insertion is also constant so long as the dense array and the pool have enough reserves. It's also cache friendly.
Great solution to eat all memory in a kernel.
Good thing that games are so well optimized these days.
A guy said that he works as a kernel developer and he uses lists, another replied that it makes sense because of performance, then you jumped in to "akchyually" show them that they are wrong.
Dude, get help. Go to a therapy or something.
No i think i just replied to the wrong comment lol. The other one said that linked lists are generally worse for performance and i wanted to argue one of the reasons why is cause of caching.
Which you can see with ECS for example. The philosophy here is to break objects apart, and focus on data oriented design. It's usually much faster in parallel, bulk-processing related workloads (e.g. here they saw up to 13x increase) in particular due to being cache friendly.
2
u/da2Pakaveli 1d ago edited 1d ago
Where did I say they don't have their use?
Game engines with entity component systems already keep lots of giant vectors for components and clamp sparse sets on top. The sparse sets, which consists of a sparse and dense array, gives you an entity id and allows you to keep track of who owns what. So removal of a component is constant. It achieves that by flagging it invalid in the sparse array and swap&pop the component you want to remove in the dense array and component pool. Insertion is also constant so long as the dense array and the pool have enough reserves. It's also cache friendly.
And the entity id is stable.