J'ai environ 3000 fichiers différents que je dois organiser et récupérer à des moments différents pendant la partie.
J'ai créé ma propre structure de variables. Je pensais à créer un "dictionnaire" Au début de ma demande, et simplement charger tous mes fichiers avant que le jeu ne commence.
Je m'interroge sur la performance: un dictionnaire avec ces nombreuses entrées entraîne-t-elle que ma demande soit lente? Un grand dictionnaire ferait-il "trygetvalue" et "contenant" courir plus lentement?
Merci pour le conseil!
7 Réponses :
3000 entrées est piddling pour un dictionnaire lire 3000 fichiers différents en mémoire au démarrage, d'autre part, les seront lents. Vous serez bien mieux mieux de lire des fichiers en mémoire uniquement au moment de leur besoin, mais de les garder en mémoire après les accès ultérieurs. <> . Ce ne sera pas une source de ralentissement.
Puisqu'il mentionne un jeu, cette règle normale peut ne pas s'appliquer. En fonction de quel point ils se chargeraient et de la taille de ce qu'ils sont, il est peut-être préférable de les charger derrière l'écran de démarrage des éclaboussures plutôt que pendant que Ashe tente de sourire une petite ...
On peut soutenir que, ils pourraient apparaître un fil d'arrière-plan lors du démarrage qui effectue le processus.
Dictionnaires en .NET Utilisez un schéma de recherche de table de hachage, l'ajout d'entrées a donc très peu d'effet, le cas échéant, sur la performance de la recherche. Le seul problème que vous aurez peut-être peut-être une utilisation de la mémoire. Un dictionnaire de 3000 éléments consommera environ 3000 fois le stockage utilisé par la clé plus les types de valeur. Si c'est juste une structure simple sans énormes blobs binaires, 3000 est carrément minuscule.
Non, ce ne sera pas. Il va consommer de la mémoire mais trygetvalue et contenant doit être assez rapide comme un dictionnaire est une hache et l'accès aux éléments par la clé est constant et il ne dépend pas de la Nombre d'éléments.
Fourniture de l'algorithme HashCode pour le type de clé de dictionnaire répandit relativement les hadrcodes de manière relativement uniformément sur l'espace INT32, la recherche de hashcode n'est pas affectée par la taille du dictionnaire.
voir http://en.wikipedia.org/wiki/hashable#performance_analysis Pour plus de détails.
+1 pour souligner que cela ne fonctionne que si le hachage n'est pas cassé.
Votre goulot d'étranglement ne sera pas la performance du dictionnaire, mais plutôt la lecture de 3000 fichiers.
Comme pour la plupart des choses avec des ordinateurs (et des performances particulières), "cela dépend (TM)"
Tout dépend de la mise en œuvre du dictionnaire.
Cela pourrait être fait sous forme d'arbre binaire, auquel cas la recherche devrait être O (log2 n), ce qui signifie que le temps de recherche augmente lentement car la taille du dictionnaire se développe.
Cela pourrait être fait comme une table de hachage, qui, en théorie, est O (1), ce qui signifie qu'une recherche prendra toujours la même quantité de temps quelle que soit la taille du dictionnaire, mais c'est la théorie, mais Dépend du nombre de godets et de qualité du code de hachage. Si de nombreux articles se retrouvent dans le même seau, nécessitant une recherche linéaire, les choses vont ralentir considérablement lorsque le dictionnaire grandit.
Cependant, le dictionnaire devrait se développer au-delà de 3000 par plusieurs ordres de grandeur avant de voir une différence notable.
Dictionnaire <> est spécifié comme à l'aide d'une table de hachage.
trygetvalue et contenant de la route doit être assez rapide à cette taille, tant que la touche a bien réparties.
Un dictionnaire a un nombre indexable de "godets". Lorsqu'il ajoute ou cherche une valeur par une clé, il faudra la valeur renvoyée par GethashCode (), le hachage à nouveau inférieur au nombre de godets (généralement quelque chose de simple comme modulo, mais la mise en œuvre n'est pas définie), et regardez dans le seau pertinent.
Le godet aura actuellement zéro ou plus d'articles. Le dictionnaire comparera chaque élément avec la clé utilisant des anneaux ().
Le premier bit de trouver le godet droit va être dans le temps constant O (1). Le deuxième bit de comparaison de la clé avec les clés du seau va être dans le temps linéaire O (n) où N ne concerne que le nombre d'éléments dans ce seau, pas dans toute la collection.
Généralement, il devrait y avoir très peu d'articles dans chaque godet (le nombre de godets se développera pour essayer de garder cela le cas) afin que l'opération soit essentiellement constante.
Si cependant, vos codes de hachage sont mal implémentés, il y aura de nombreuses clés dans le même seau. La complexité de temps sera plus proche et plus proche de O (n), comme on peut le voir en expérimentant un objet avec un mot délibérément mauvais gethascode qui retourne à chaque fois. Dans son cas pire, c'est pire qu'une liste, puisque une liste est également O (n), mais le dictionnaire a plus de frais généraux.
Quelqu'un signifie-t-il que vous devriez vous inquiéter? Non, même des méthodes de hachage relativement naïve devraient donner des résultats relativement bons. Si vous utilisez une clé à cordes, cela va probablement être plus que suffisamment bon. Si vous utilisez un simple type intégré, alors encore plus.
Si vous constatez que l'accès au dictionnaire est lent, alors vous souhaitez faire attention à cela et corriger la méthode gethashcode () ou créer un iéquitycomparer (qui vous permet de définir des règles extérieures pour GethashCode () et de l'équivalence () Pour une utilisation avec des dictionnaires, des hashsets, etc.).
Très probablement, 3000 n'est rien, ça ira bien.