Well, shame on me. I didn’t resist the urge of giving you some numbers on the aspect that you pretend to know but insist to ignore during your analysis.
I prepared some tests to compare groups for 6 types and 10k entities (the same examples from @OvermindDL1) and going from full-owning to non-owning groups.
Here are the results:
full-owning group, 6 of 6: 19us
partial-owning group, 5 of 6: 32us
partial-owning group, 4 of 6: 35us
partial-owning group, 3 of 6: 40us
partial-owning group, 2 of 6: 45us
partial-owning group, 1 of 6: 53us
non-owning group, 0 of 6: 87us
For your information, I run the tests 10k times each and filtered a good number of spikes every time (max/min).
My times are different from that of @OvermindDL1 for obvious reasons but we remember from his tests that your design was up to more than twice as slower if compared to full-owning groups and in the theoretical best case for archetypes (something like that at least, I haven’t re-read the comment).
So, what we deduce from these numbers that we don’t deduce from your overwhelming experience?
We see that up to 3/4 free types in a group, the performance are still comparable if not even in favor of groups (and you’ve still a problem with creation/destruction but let’s ignore it for a moment). However, this isn’t important imho since this kind of benchmarks are pointless from my point of view and highly subjected to factors that are present only in real world applications (eg fragmentation for archetypes, distribution for partial-owning groups, and so on, all things that do exist despite your attempts to minimize them).
What is important instead is that there is no worst path here, no matter how many times you mentioned it. That was the whole point of your thesis and it was just wrong. You aren’t jumping from 1us to 1ms all of a sudden because of a free type, that’s all.
With groups, nested groups and partial-owning groups you can easily cover all queries, this is a fact and if you really have experience with this model I think we can easily agree on this point. Non-owning groups are there just because they are a logical consequence of their counterparts but I’ve never found a good use for them actually.
Now consider that 4 free types are a lot for a group though. Before to continue, do you know what I mean with free type? I guess so but ask if it’s not clear.
I’m pretty sure that now you could start saying that queries with 20 types and 15 free types are extremely common and that if I don’t use them I don’t exploit all the potentials of an ECS and bla bla bla so as to adjust the numbers above but they are not, we both know it.
So, in general, groups with free types are rare as heck at gameplay level where queries are way smaller and usually targeted to specific features, even more those with 4+ free types (since now it’s clear that you’ve never worked with groups apparently, please don’t start saying that in your experience they are extremely common instead, it would be embarrassing).
However, you can hit non-overlapping nor disjointed groups among the others probably (almost surely) in lower levels, granted. Anyway, they won’t be the vast majority and only an irrelevant portion of them will have 5+ free types (most likely none but who knows, let’s suppose there are some). Even in this case though, what you gain in all cases where iterations are faster you can spend in part where you’ve 5+ free types and you’re still there in terms of performance.
So, all in all, am I saying that groups and sparse sets are better? No, these numbers prove nothing, they give just a measure but real world applications are way more complex and many other factors pull in and alter the results. Do we agree on this?
What I’m saying is that the two solutions are in the same ballpark and your assumptions (that were based on your not better defined experience with groups) were just wrong because you never really explored this model.
What is scaring is that there is a community that should make a choice based on a trust me and my experience according to the way you prove your assumptions.
However, again, I’m not the one that is selling his library here, so who cares. I said I was out and I’ll stop here the contributions. You had your answer, your numbers, an explanation of what partial-owning groups are and how they perform, an overview of what puts these models in the same ballpark despite your guess. I’ve really spent too much time on this, I hope you appreciate it at least!
If you want to continue to dispatch theses based on nothing and supported only by an in my experience, it’s not my problem now. If you can stop offending, change attitude towards me and start reasoning instead, I’m willing to rewind and restart a sane discussion. One in which you assume that I know more than you about a model that you proved to have never tried hard to use (and viceversa ofc).
Side note. A friend of mine just pointed out this in the ECS core of Unity: https://docs.unity3d.com/Packagesfirstname.lastname@example.org/manual/entity_iteration_foreach.html
You can use ForEach lambda functions with up to six types of components.
I’m not an Unity user so I may be wrong and ofc you can get around the limitation. Moreover this tool serves only specific purposes. However, either they are simplifying things only for those that don’t use an ECS in all its potentials or 8+ queries aren’t that common after all and they decided to somehow address only the most commons for some reasons (most likely optimizations?).
I dunno but it’s interesting. Anyway, feel free to ignore this rant.