Discussion :

[Jerede]

Bonsoir,

Je suis actuellement confronté à un problème pour mon jeu.
Le World est donc composé de Continents, qui sont composé de Regions, ect..
Voila donc la structure grossière.

World -> Continents -> Régions -> Zones -> Maps.

Après viennent s'ajouter les personnages ( et les problèmes aussi ).

1. Dois-je mettre un seul Dictionnaire de Personnage pour le World. Pour récupérer les personnages présent sur une Map, je devrai donc faire une recherche dans le dictionnaire du World.

2. Ou dois-je avoir un dictionaire pour chaque Map, Zones, Regions, Continents et pour le World. Cela me permettrai d'avoir un accès direct aux personnages présents sur la carte ( ce qui est souvent utilisé, pour les déplacements, t'chat.. ), bien que chaque changement de carte entrainerai des ajouts/suppression conséquentes dans les dictionnaires.

En sachant que l'application est mulithreadé et donc, qu'a chaque accès aux dictionnaires, on a un lock.

Merci d'avance

[Dr Dédé]

Un dictionnaire .net pourrait rencontrer des problèmes de performance au-delà de 5 millions d'éléments, selon ce message à Stackoverflow.com, parce qu'il devra se mettre à chercher des nouveaux nombres premiers.

Cela dit, à moins que vous ayiez réellement un si grand nombre de personnages, votre problème de performance majeur ici est d'avoir à acquérir un lock sur chaque accès au dictionnaire. Si les accès sont fréquents, vous perdez pratiquement tout avantage de performance que le multi-thread peut vous procurer. Une stratégie de caching local par thread serait à considérer pour minimiser les accès concurrents.

[Arnard]

Ya le ConcurrentDictionnary en .Net 4, avec une gestion optimisée des locks...

Perso je choisirai la solution 1, après tout dépend le volume d'accès concurrentiel, on peut avoir un ordre d'idée ? Des tests de simulation avec création de X threads représentant les mouvements/chats/autres actions peut aussi s'avérer être un test intéressant...

Et sinon, ReaderWriterLockSlim peut être une classe sympa dans ton cas (utilisée par ConcurrentDictionnary si je ne m'abuse). Ce qu'il faut déterminer, c'est le ratio lecture/ecriture dans ton application

[Jerede]

Un dictionnaire .net pourrait rencontrer des problèmes de performance au-delà de 5 millions d'éléments, selon ce message à Stackoverflow.com, parce qu'il devra se mettre à chercher des nouveaux nombres premiers.

La liste du World atteindrai les 5000 joueurs maximums, donc pas de problème de ce niveau là.

Ya le ConcurrentDictionnary en .Net 4, avec une gestion optimisée des locks...

Perso je choisirai la solution 1, après tout dépend le volume d'accès concurrentiel, on peut avoir un ordre d'idée ? Des tests de simulation avec création de X threads représentant les mouvements/chats/autres actions peut aussi s'avérer être un test intéressant...

Et sinon, ReaderWriterLockSlim peut être une classe sympa dans ton cas (utilisée par ConcurrentDictionnary si je ne m'abuse). Ce qu'il faut déterminer, c'est le ratio lecture/ecriture dans ton application

Ce serait plutôt de l'ordre de :
10 accès à la liste de personnages de la carte par ms. (Donc dans le cas 1, faire une recherche depuis la liste du World, dans le cas 2, accès direct depuis la liste de la Map)
1ajout/suppresion par ms. ( Dans le Cas oû les personnages lors de leur changement de carte doivent être switché de liste )

Pour le ReaderWriterLockSlim, je ne crois pas que ce soit possible car deux threads peuvent ajouter des joueurs dans la liste en même temps.