Without information on exactly what the data looks like, it is hardly possible to suggest suitable data structures. For an unknown number of data records, for example, a vector could be considered. Considering a scenario where the data per player can grow over time, it is important to choose a data structure that can handle the addition of new data efficiently. Important parameters would be access speed, insertion efficiency and memory consumption. An unordered_map could be favorable on average. System performance and memory consumption should be investigated. Often a combination of several data structures is advantageous, enabling both fast lookups and efficient insert operations.
Without more specific information about which data should be stored and how it should be accessed, it is almost impossible to make a concrete recommendation.
//edit:
Quote:
now imagine performing checks on 1000 players at once
The requirement that it should be possible to update a large number of active players and calculate interactions efficiently can be met by multithreading. Multithreading makes it possible to execute tasks in parallel and thus improve performance, especially when it comes to processing a large amount of data.
Simultaneous access to shared data usually requires synchronization. This can be done by using mutexes, atomic operations or other synchronization techniques.
The selected data structure must be thread-safe or appropriately secured to ensure that multiple threads can access it safely without causing data corruption.
Standard library data structures such as unordered_map and vector require additional synchronization as they are usually not automatically thread-safe.
Presumably, it would be easier to achieve thread safety with vector, since the elements are arranged sequentially in memory and access to different indices can possibly be parallelized. The interference with accesses to an unordered_map could be more difficult to handle with multithreading.
Submit an article or tip