Discussion :

[coda_blank]

Bonsoir, je cherche en C++ une lib offrant table d'association rapide avec en cl� une std::string et en valeur un pointeur (sous gcc 4.5)

C'est une application graphique qui tourne en 60 frames/sec
Je dois faire un lookup sur une table de 10000 entr�es environ et 10000 appels
par frame

j'�tais parti sur std::unordered_map mais elle n'a pas l'air d'�tre tr�s efficace sur les string m�me avec 01 ou 02 activ�s (enfin compar� � une cl� en int)

Faut il que je m'oriente vers une solution "� la main" ?

[koala01]

Salut,

Le fait est que tu n'auras JAMAISde bonnes perfs en utilisant une chaine de caract�res comme cl�.

La raison est tout simplement la m�thode de comparaison de celles-ci : il faut comparer caract�res par caract�res jusqu'� trouver (ou non) une diff�rence, et cela implique une boucle !

Une valeur strictement num�rique, qui soit comparable "en une seule fois" donnera forc�ment des performances bien meilleures

[screetch]

en m�me temps c'est bien pour ca qu'on a invent� le hash qui permet de ne pas comparer les cha�nes trop souvent
a mon avis le probl�me que tu as c'est qu'avec tes std::string tu fais des allocations en permanence. Mais c'est juste une devinette, parce que en fait les vrais programmeurs utilisent un profiler de code pour savoir ce qui co�te cher. Ils disent pas au pif comme moi :o)

[coda_blank]

Salut,

Le fait est que tu n'auras JAMAISde bonnes perfs en utilisant une chaine de caract�res comme cl�.

La raison est tout simplement la m�thode de comparaison de celles-ci : il faut comparer caract�res par caract�res jusqu'� trouver (ou non) une diff�rence, et cela implique une boucle !

Une valeur strictement num�rique, qui soit comparable "en une seule fois" donnera forc�ment des performances bien meilleures

C'est bien ce que je pensais, il me fallait juste confirmation

Par contre y a t il moyen de faire mieux que la STL si on se cantonne au couple int/pointeur

[Emmanuel Deloget]

C'est bien ce que je pensais, il me fallait juste confirmation

Par contre y a t il moyen de faire mieux que la STL si on se cantonne au couple int/pointeur

Mieux que quoi dans la STL ? Si tu parles de std::map<>, oui, il y a mieux. Dans le TR1, on a unordered_set/unordered_multiset qui sont grosso-modo des tables de hash. Avec une fonction de hashage optimale, chercher un �l�ment dans ces ensembles est une op�ration de complexit� constante (ind�pendante du nombre d'�l�ments ins�r�s).

[Klaim]

Cela dit il a d�j� tent� unordered_map, comme dit dans le premier post.

Le probl�me est fondamentalement difficile de toutes fa�ons, juste changer de conteneur �a ne suffira jamais.

Si les donn�es sont ind�pendantes, peut �tre qu'en organisant ton traitement en parall�le �a aidera? Ca d�pends si tu as plusieurs coeurs d'execution sur ta cible cela dit.

Pour faire mieu niveau perfs, il faut voir plus haut, donc savoir plus de choses sur ce qui est trait� comme donn�es et le contexte.

[JolyLoic]

La table de hash est plus performante en complexit�, mais pas forc�ment en pratique. J'ai eu des retours o� std::map explosait std::unordered_map tant que les jeux de donn�e n'explosaient pas le million. Un des probl�mes avec une table de hash est le choix de la fonction de hash. La tienne est-elle bonne par rapport aux strings que tu manipules ? As-tu beaucoup de collisions ?


Est-ce que tu as souvent besoin d'acc�der aux m�mes �l�ments ? Si oui, un splay tree pourrait �tre int�ressant.

10000 entr�es et 10000 appels par frame, pourquoi le m�me nombre ? Ne peux-tu pas r�organiser ton algorithme pour faire moins d'appels ?

[pyros]

Si ta clef est un int qui n'est jamais trop grand (genre < 10000), tu peux essayer un b�te std::vector de taille MAX_KEY. Niveau conso m�moire, tu aura un rendement proche du n�ant avec beaucoup de cases inutiles, mais niveau perf tu acc�dera � tes �l�ments en temps constant... Parfois, c'est un compromis acceptable.

[Klaim]

En fait un vector ou un array c'est ce que j'ai pens� en premier mais je me dis que c'est le "cas id�al" et du coup si ya moyen de parall�liser �a pourrait �tre encore plus rapide.