6
votes

Vitesse de la recherche de la valeur du dictionnaire .NET par clé?

J'ai un dictionnaire de 10000 combinaisons de produits / couleur / taille que j'ai créés avec quelque chose comme: xxx

donc un exemple de clé est comme "13ai_grs_m"

Je dois synchroniser ma base de données avec l'ERP de la société toutes les 30 minutes et pour chaque combo de couleur / taille, je dois utiliser ce dictionnaire pour ajouter, modifier ou supprimer des enregistrements. Je souhaite qu'ils fournissaient des numéros d'identification.

Je ne sais pas comment le dictionnaire fonctionne en interne. Quelle est la rapidité de .NET à la recherche de la bonne valeur basée sur une telle clé? Devrais-je trier la requête de la base de données ou .net avoir une autre façon d'identifier la clé?

ou devrais-je le convertir en liste et utiliser un dictionnaire pour identifier le bon indice? Ou une autre solution complètement?

J'utilise également des dictionnaires statiques de cette manière partout dans la demande de site Web, alors apprendre une meilleure façon de faire cela aurait une influence assez d'influence.

Merci beaucoup, Steve


2 commentaires

Merci beaucoup pour vos réponses. Je ne suis pas encore nouveau sur le site, je n'ai pas encore appris l'étiquette, mais j'ai réalisé que j'ai posé une question sur laquelle 5 personnes ont tous souligné que le code "est ok", pour diverses raisons. Devrais-je les marquer tous comme utiles? Merci encore. Steve


Vous ne pouvez marquer que 1 comme «accepté». Utilisez simplement votre jugement.


5 Réponses :


1
votes

Les dictionnaires sont faits pour rechercher les choses, alors restez avec ça. Le problème principal du type clé est qu'il devrait avoir un bon code de hachage (bien distribué).

Vous pouvez écrire votre propre KeyClass avec des membres de produit, ColourCode et Sizecode, mais vous devrez ensuite surcharger le gethashcode et les membres égaux (et associés). Et il sera assez difficile de s'améliorer sur le gethashcode de System.string et assez facile à faire des erreurs.

Alors, ne vous embêtez pas. Votre chaîne de clé semble ok.

Et si vous souhaitez optimiser, profil d'abord pour voir où sont vos problèmes.


2 commentaires

Merci de me diriger vers une zone de .NET, je n'étais pas au courant .. autre chose à rechercher!


Exactement, ne vous inquiétez pas trop sur la performance jusqu'à ce qu'il s'agisse d'un problème réel, puis de l'identifier avec un profileur, ce n'est souvent pas où vous le pensez.



1
votes

Trouver une valeur par clé est très rapide et l'utilisation d'un dictionnaire semble être absolument appropriée. La clé que vous créez me semble aussi ok. La prétention de la base de données n'a absolument aucun sens, le dictionnaire ne dépend pas de cela.


0 commentaires

5
votes

Pour ce que vous faites, le dictionnaire est parfait.

Le temps de récupération sur les touches des éléments d'un dictionnaire est je suis , mais s'appuie finalement sur la fonction de code de hachage de la clé (dans votre cas string.gethashcode () ).

Vous avez de la chance, car la fonction gethashcode de .NET String est très bonne. Si vous obtenez un clash de code de hachage, .Net appellera la méthode Equals sur l'objet, et garantit ainsi l'unicité.

Nous avons des dictionnaires avec des centaines de milliers d'articles, et les temps de recherche sont négligeables.

Tri des résultats de la base de données ne bénéficiera d'aucun avantage dans ce cas.

J'espère que cela aide.


0 commentaires

2
votes

Quelle vitesse est rapide à la recherche de la bonne valeur basée sur une telle clé?

La complexité de la récupération d'une valeur pour une clé est proche de O (1) Selon MSDN , il est donc assez rapide ...

Aussi de MSDN:

La vitesse de récupération dépend de la qualité de l'algorithme de hachage du type spécifié pour TKEY.

Si vous utilisez une chaîne comme clé, vous devriez être correct, car nous pouvons probablement supposer que la classe string utilise un algorithme de hachage efficace ...


3 commentaires

Thomas, excuses d'avoir été pédants, mais qu'une opération a une faible complexité, ne signifie sûrement pas que c'est intrinsèquement rapide. Ce sera plus rapide qu'une opération avec une complexité élevée, mais si l'algorithme sous-jacent est complexe, la grande notation peut être faible, mais l'opération peut toujours être lente. Ou je parle de mon cul? (Je ne suis pas expert sur le Big O)


Vous avez raison, la complexité n'est pas la seule chose à prendre en compte, mais la complexité non constante aurait un impact majeur sur la vitesse de récupération réelle que le dictionnaire grandit. Il ne peut que être si rapide parce que la complexité est O (1)


J'ai sauté en programmation avec les langues relativement de haut niveau et je n'ai jamais eu à s'inquiéter des algorithmes de tri. Je suis heureux que je n'ai pas besoin de maintenant. Merci pour vos réponses.



0
votes

J'utilise ce "motif" assez fréquemment, si vous ne pouvez pas obtenir des requêtes SQL (surtout sur SQL CE) pour courir assez vite.

Vous voudrez peut-être examiner la fonction TolOOKUP, car je le trouve plus pratique dans la majorité des cas. Les vitesses de recherche ne sont pas affectées, il utilise un dictionnaire mappé sur des collections.


1 commentaires

Tolookup () va aussi aider énormément à l'avenir, merci.