Most efficient way to determine which components an entity possesses?

[Net5F]

I'm trying to streamline my system for synchronizing components between a client and server, and my current idea is to do something like:

// This message is sent when an entity first comes in range of a client
struct EntityInitMessage
{
    std::vector<std::variant<list_of_components>> components;
};

std::vector<entt::entity> entitiesToSend{<this is filled elsewhere>};
std::unordered_map<entt::entity, EntityInitMessage> messageMap;

"For each component type T in list_of_components"
    for (entt::entity entity : entitiesToSend) {
        if (auto component = registry.try_get<T>(entity)) {
            addComponentToMessage<T>(messageMap[entity], *component);
        }
    }

Does it seem sane to make this the backbone of the process I'm building (potentially calling try_get() hundreds or thousands of times in a frame, if many clients come in range of new entities)? Or is there a more efficient approach that I should take for determining which components are on an entity?

I know that internally each component is given an integer index, but I'm guessing the registry doesn't build lists of the component indices that each entity possesses? I could do that externally using on_construct and on_destruct callbacks. It seems like that might be a more efficient approach for this problem, but the cost of maintaining a vector per entity might make it not worthwhile.

[skypjack]

Yeah, keeping the list of components for each entity has its pros and cons and the right approach really depends on the final use.
For example, in a game on which I've worked in the past we only tracked components on addition. The final list can contain false positives but the solution doesn't hurt performance if you have many creations/deletions.
Also, when it comes to sharing data between client and server, you don't even want to send all components most of the time. As a trivial example, a flyweight-like handle for a renderable object or an input listener tag aren't of interest in this context probably.
I'd probably flip the problem on its head then and send only the components of interest once combined with the list of entities to send. The latter can be part of a sparse set and thus combined in a view with the other storage classes.

[Net5F]

Also, when it comes to sharing data between client and server, you don't even want to send all components most of the time.

Good point that I should have mentioned, my list_of_components is actually a list of only the components that the client cares about.

I'd probably flip the problem on its head then and send only the components of interest once combined with the list of entities to send. The latter can be part of a sparse set and thus combined in a view with the other storage classes.

A complicating factor is that the entities that I need to send may not have all of the components in the list. One entity may have a couple of the components, another may have a couple different ones. Is it true then that a view would exclude them, since they don't possess all the types (and thus the view would not be useful to me)? Or does adding this sparse set of entities change the behavior?

[skypjack]

I'd serialize types separately and send them separately to the server actually. In this case, the problem doesn't exist. 🤷‍♂️