C # binaire Arbres et dictionnaires

Question

C # binaire Arbres et dictionnaires

voix

15

Je me bats avec le concept de quand utiliser les arbres binaires de recherche et quand utiliser des dictionnaires.

Dans ma demande , je l'ai fait une petite expérience qui a utilisé la bibliothèque C5 TreeDictionary(qui je crois est un arbre de recherche binaire rouge-noir), et le dictionnaire C #. Le dictionnaire a toujours été plus rapide à ajouter / trouver des opérations et aussi toujours utilisé moins d' espace mémoire. Par exemple, à 16809 <int, float>entrées, le dictionnaire utilisé 342 Kio tandis que l'arbre utilisé 723 Kio.

Je pensais que ce BST étaient censés être plus efficace mémoire, mais il semble qu'un nœud de l'arbre nécessite plus d'octets d'une entrée dans un dictionnaire. Ce qui donne? Y at-il un point où est BST sont meilleurs que les dictionnaires?

En outre, comme une question de côté, personne ne sait s'il y a une structure de données plus rapide + plus efficace de mémoire pour stocker des <int, float>paires d'accès de type dictionnaire que l'une des structures mentionnées?

c#dictionary binary-search-tree c5

Créé 28/01/2010 à 02:46
source utilisateur Projectile Fish

Dans d'autres langues...

6 réponses

voix

1

Il me semble que vous faites une optimisation prématurée.

Ce que je vous propose est de créer une interface pour isoler la structure qui vous êtes réellement en utilisant, puis implémenter l'interface en utilisant le dictionnaire (qui semble fonctionner le mieux).

Si la mémoire / performance devient un problème (qui ne sera probablement pas pour 20k- numéros), vous pouvez créer d'autres implémentations d'interface, et vérifiez que l'on travaille meilleures performances. Vous aurez pas besoin de changer quoi que ce soit presque dans le reste du code (sauf que la mise en œuvre que vous utilisez).

Créé 28/01/2010 à 03:26
source utilisateur Samuel Carrijo

voix

1

Il est logique qu'un noeud d'arbre nécessiterait plus de stockage que une entrée de dictionnaire. Un nœud d'arbre binaire doit stocker la valeur et les deux sous - arbres gauche et à droite. Le générique Dictionary<TKey, TValue>est utilisé comme une table de hachage qui - je suppose - utilise soit une liste chaînée pour chaque godet (valeur plus un pointeur / référence) ou une sorte de remappage (juste la valeur). Je dois avoir un coup d' oeil dans le réflecteur pour être sûr, mais dans le but de cette question , je ne pense pas qu'il est important.

Le clairsemés la table de hachage, moins efficace en termes de stockage / mémoire. Si vous créez une table de hachage (dictionnaire) et initialisez sa capacité à 1 million, et remplir avec seulement 10.000 éléments, alors je suis sûr que ce serait manger beaucoup plus de mémoire qu'un BST avec 10.000 nœuds.

Pourtant, je ne vous inquiétez de tout cela si la quantité de nœuds / clés est seulement dans les milliers. Cela va être mesuré dans les kilo-octets, par rapport à giga-octets de RAM physique.

Si la question est « pourquoi vous voulez utiliser un arbre binaire au lieu d'une table de hachage? » Ensuite, la meilleure réponse est l'OMI que les arbres binaires sont commandés alors que des tables de hachage ne sont pas. Vous ne pouvez rechercher une table de hachage pour les clés qui sont exactement égales à quelque chose; avec un arbre, vous pouvez rechercher une plage de valeurs, valeur la plus proche, etc. Cette distinction est très important si vous créez un index ou quelque chose de similaire.

Créé 28/01/2010 à 03:39
source utilisateur Aaronaught

voix

0

L'interface pour un arbre et une table de hachage (que je devine est ce que votre dictionnaire est basé un) devrait être très similaire. Toujours tournant autour calées lookups.

J'avais toujours pensé un dictionnaire valait mieux pour créer des choses une fois, puis ensuite faire beaucoup de recherches là-dessus. Alors qu'un arbre était mieux si vous le modifier de manière significative. Cependant, je ne sais pas où je pris cette idée à partir.

(Les langages fonctionnels utilisent souvent les arbres comme base pour qu'ils collections que vous pouvez réutiliser la plupart de l'arbre si vous faites de petites modifications à elle).

Créé 28/01/2010 à 03:40
source utilisateur ligos

voix

0

Vous n'êtes pas comparer « des pommes avec des pommes », un BST vous donnera un ordre de représentation alors qu'un dictionnaire vous permet de faire une recherche sur une paire de valeurs clés (dans votre cas).

Je ne serais pas attendre taille beaucoup plus dans l'empreinte mémoire entre le 2, mais le dictionnaire vous donne une recherche beaucoup plus rapide. Pour trouver un élément dans un BST vous (potentiellement) besoin de traverser l'arbre entier. Mais pour faire une recherche dictnary vous lookup simplement basée sur la clé.

Créé 28/01/2010 à 04:05
source utilisateur nixon

voix

0

Un BST équilibré est préférable si vous avez besoin pour protéger votre structure de données à partir des pics de latence et les attaques de collisions de hachage.

L'ancien qui se passe quand une structure soutenue matrice-pousse une obtient redimensionnée, ce dernier est une propriété inévitable de l'algorithme de hachage comme une projection de l'espace infini à une plage de nombre entier limité.

Un autre problème dans .NET est qu'il ya LOH, et avec un dictionnaire suffisamment grand vous exécutez dans une fragmentation de LOH. Dans ce cas, vous pouvez utiliser un BST, payer un prix de classe de complexité algorithmique plus grande.

En bref, avec un BST soutenu par le tas d'allocation que vous obtenez le pire des cas O (log (n)), avec Hashtable vous obtenez O (N) pire moment de cas.

BST vient à un prix de O (log (n)) moyenne, localité pire cache et plus allocations de tas, mais il a des garanties de temps d'attente et est protégée contre les attaques de dictionnaire et la fragmentation de la mémoire.

A noter que la BST est un sujet à la fragmentation de la mémoire sur d'autres plates-formes, ne pas utiliser un éboueur compactage.

En ce qui concerne la taille de la mémoire, la classe .NET Dictionary`2 est plus efficace de la mémoire, car il stocke les données comme une liste chaînée hors tas, qui ne stocke la valeur et l'information de décalage. BST doit stocker en-tête d'objet (comme chaque nœud est une instance de classe sur le tas), deux pointeurs, et quelques données sur les arbres pour les arbres équilibrés augmentée. Par exemple, un arbre rouge-noir aurait besoin d'un booléen interprété comme la couleur (rouge ou noir). Ceci est au moins 6 mots de la machine, si je ne me trompe pas. Ainsi, chaque noeud dans un arbre rouge-noir sur un système 64 bits est au minimum de:

3 mots pour l'en-tête = 24 octets 2 mots pour les pointeurs de l'enfant = 16 octets 1 mot pour la couleur = 8 octets au moins 1 mot pour la bytes = 24 + 16 + 8 + 8 = 56 octets de la valeur (+8 octets si l'arbre utilise un pointeur de nœud parent).

En même temps, la taille minimale de l'entrée du dictionnaire serait seulement 16 octets.

Créé 10/12/2018 à 13:18
source utilisateur George Polevoy

Juliet · Accepted Answer · 2010-01-28 04:16

Je pensais que ce BST étaient censés être plus efficace mémoire, mais il semble qu'un nœud de l'arbre nécessite plus d'octets d'une entrée dans un dictionnaire. Ce qui donne? Y at-il un point où est BST sont meilleurs que les dictionnaires?

J'ai personnellement jamais entendu parler d'un tel principe. Même encore, son seul principe général, et non un fait catégorique gravé dans le tissu de l'univers.

En général, Les dictionnaires sont vraiment juste un emballage de fantaisie autour d'un tableau de listes chaînées. Vous insérez dans le dictionnaire quelque chose comme:

LinkedList<Tuple<TKey, TValue>> list =
    internalArray[internalArray % key.GetHashCode()];
if (list.Exists(x => x.Key == key))
    throw new Exception("Key already exists");
list.AddLast(Tuple.Create(key, value));

Ainsi , sa presque opération O (1). Le dictionnaire utilise O (internalArray.Length + n) de mémoire, où n est le nombre d'éléments de la collection.

En général BSTS peut être mis en œuvre:

listes liées, qui utilisent l'espace O (n), où n est le nombre des éléments de la collection.
réseaux , qui utilisent O (2 ^h - n) espace où h est la hauteur de l'arbre et n est le nombre d'éléments de la collection.
- Étant donné que les arbres rouge-noir ont une hauteur limitée de O (1,44 * n), une mise en œuvre du tableau doit avoir une utilisation de la mémoire limitée d'environ O (2 ^1.44n - n)

Les chances sont, la C5 TreeDictionary est mis en œuvre en utilisant des tableaux, ce qui est probablement responsable de l'espace perdu.

Ce qui donne? Y at-il un point où est BST sont meilleurs que les dictionnaires?

Les dictionnaires ont des propriétés indésirables:

Il assez blocs continugous peut ne pas être de mémoire pour maintenir votre dictionnaire, même si ses besoins en mémoire sont beaucoup moins que le total de RAM disponible.
L' évaluation de la fonction de hachage peut prendre une longueur arbitrairement longue. Les chaînes, par exemple, utiliser réflecteur pour examiner la System.String.GetHashCodeméthode - vous remarquerez hachant une chaîne prend toujours O (n), ce qui signifie qu'il peut prendre beaucoup de temps pour de très longues chaînes. Sur la main, la comparaison des chaînes de l' inégalité presque toujours plus vite que le hachage, car il peut exiger que regarder seulement les premiers caractères. Son tout à fait possible pour les inserts d'arbres plus rapide que les inserts dictionnaire si l' évaluation du code de hachage prend trop de temps.
- Int32 de GetHashCodela méthode est littéralement juste return this, alors vous seriez hardpressed de trouver un cas où une table de hachage avec les touches int est plus lent qu'un dictionnaire d'arbre.

RB Les arbres ont des propriétés souhaitables:

Vous pouvez trouver / supprimer les éléments Min et Max en O (log n), par rapport à O (n) en utilisant un dictionnaire.
Si un arbre est mis en œuvre comme liste chaînée plutôt qu'un tableau, l'arbre est généralement plus efficace que l' un dictionnaire.
De même, son ridicule facile d'écrire des versions immuables d'arbres qui prennent en charge insert / recherche / supprimer dans O (log n). Les dictionnaires ne sont pas bien adaptées à immuabilité, puisque vous devez copier l'intégralité du tableau interne pour chaque opération ( en fait, je l' ai vu de la structure de dictionnaire de données à usage général des implémentations de tableau-des arbres des doigts immuables, un de type, mais la mise en œuvre est très complexe).
Vous pouvez parcourir tous les éléments dans un arbre dans l'espace afin Sorted constant et le temps O (n), alors que vous auriez besoin de vider une table de hachage dans un tableau et le tri pour obtenir le même effet.

Ainsi, le choix de la structure de données dépend vraiment de ce que les propriétés dont vous avez besoin. Si vous voulez juste un sac et peut garantir non ordonné que votre fonction de hachage d'évaluer rapidement, aller avec un .Net dictionnaire. Si vous avez besoin d'un sac ordonné ou avoir une fonction de hachage de marche lente, aller avec TreeDictionary.