performances pour les lectures de nsdictionary vs nsarray

Poursuite de cette publication: impact sur les performances lié à l’utilisation de NSMutableDictionary par rapport à NSMutableArray>

J’essaie de faire un petit test pour voir si l’écart de performance est si grand pour la lecture et l’écriture entre NSArray et NSDictionary ainsi que leurs coutnerparts mutables …

Cependant, j’ai du mal à trouver un test “équilibré” … car le dictionnaire contient 2 objects (ou 3 selon votre perception) à boucler pour obtenir la valeur (et non la clé) recherchée, alors que le tableau n’a que un…

Aucune suggestion?

Si vous voulez plus de détails: ce que je veux dire est plus facile à expliquer à travers des exemples;

Pour le tableau: (pour NSSsortingng * str dans le tableau) {a smth avec la chaîne}

Pour le dictionnaire

(for NSSsortingng *str in [dictionary allValues]) { ssortingng } 

OU

 (for NSSsortingng *str in [dictionary allKeys]) { [dictionary valueForKey:key] } 

OU

 (for NSSsortingng *str in [dictionary allKeys]) { ssortingng } 

OU MÊME

 NSArray *valuesOrKeys = [dictionary allKeys/allValues]; (for NSSsortingng *str in valuesOrKeys) {ssortingng } 

Quel est le test “le plus juste” à faire pour le dictionnaire?

–EDIT (commentaire)

Comme vous l’avez tous souligné (et demandé pourquoi je voudrais cela), lorsqu’un dictionnaire est utilisé, c’est qu’il convient mieux au modèle qu’un tableau …

La raison de ma demande est qu’une application que je suis en train de créer est extrêmement lente et j’essaie donc de savoir si l’utilisation d’un type de données différent changerait tout cela, et j’envisage d’utiliser des tableaux de base c … J’ai le choix à ce stade, donc je suis en mesure de changer le fonctionnement interne pour s’adapter à tout type que je veux …

J’aimerais vous signaler l’article suivant: ” Array “, de ridiculous_fish , ingénieur chez Apple. Les baies de cacao ne sont pas nécessairement des baies naïves bien implémentées, contrairement aux dictionnaires, et les dictionnaires ne sont pas de simples tables de hachage. Leur performance est très circonstancielle et dépend du nombre d’objects qu’ils détiennent (ainsi que de leurs valeurs, etc.). Cela n’affectera peut-être pas directement la réponse, mais c’est un élément à prendre en compte (les performances de NSDictionary évidemment en fonction de la vitesse et de la fiabilité de votre fonction de hachage, etc.).

De plus, si vous recherchez un test «équilibré», vous devez rechercher un moyen de faire en sorte que les deux classes se comportent aussi près que possible de l’autre. Vous voulez exclure l’access aux valeurs via les clés du dictionnaire, car, quelle que soit la rapidité de la recherche des structures de données sous-jacentes gérées par NSDictionary , il est plus lent que de simplement extraire des objects d’un tableau, car vous effectuez davantage d’opérations. il. L’access à partir d’un tableau est O(1) , pour une table de hachage, O(1) au mieux et O(n) au pire (selon l’implémentation, quelque part au milieu).

Comme vous l’avez mentionné ci-dessus, il existe plusieurs méthodes pour énumérer les dictionnaires et les tableaux. Vous allez vouloir utiliser les méthodes les plus proches les unes des autres en termes d’implémentation, soit une énumération basée sur des blocs ( enumerateObjectsUsingBlock: for NSArray et enumerateKeysAndObjects: pour NSDictionary ), ou une énumération rapide (utilisant allKeys ou allValues pour le NSDictionary ). Les performances de ces algorithmes étant principalement empiriques, j’ai effectué plusieurs tests pour noter les temps d’access (avec chacun 10 NSNumber objects NSNumber ):

 NSArray, Block Enumeration: 1. 10.5s 2. 9.1s 3. 10.0s 4. 9.8s 5. 9.9s ----- 9.9s Avg NSArray, Fast Enumeration: 1. 9.7s 2. 9.5s 3. 9.3s 4. 9.1s 5. 10.5s ----- 9.6s Avg NSDictionary, Block Enumeration 1. 10.5s 2. 10.6s 3. 9.9s 4. 11.1s 5. 11.0s ----- 10.6s Avg NSDictionary, allKeys -> Fast Enumeration 1. 10.0s 2. 11.2s 3. 10.2s 4. 10.8s 5. 10.8s ----- 10.6s Avg NSDictionary, allValues -> Fast Enumeration 1. 10.7s 2. 10.3s 3. 10.5s 4. 10.5s 5. 9.7s ----- 10.3s Avg 

Comme vous pouvez le constater d’après les résultats de ce test artificiel, NSDictionary est nettement plus lent que NSArray (environ 7% moins rapide avec l’énumération par blocs et 7-10% plus lente avec l’énumération rapide). Cependant, cette comparaison est plutôt inutile, étant donné que l’utilisation de l’énumération la plus rapide pour NSDictionary simplement dans un tableau.

La grande question est donc: pourquoi envisageriez-vous d’utiliser un dictionnaire? Les tableaux et les tables de hachage ne sont pas exactement interchangeables. Quel type de modèle avez-vous qui permet le remplacement NSDictionary de NSArray par NSDictionary ? Quels que soient les délais donnés par des exemples artificiels pour prouver les avantages de performances d’une manière ou d’une autre, vous devez toujours mettre en œuvre vos modèles de manière sensée – vous pouvez optimiser les performances ultérieurement si vous devez. Je ne vois pas comment vous utiliseriez ces structures de données de manière interchangeable, mais de toute façon, NSArray est le gagnant ici, en particulier en considérant l’ordre séquentiel dans lequel vous essayez d’accéder aux valeurs.

Voici votre test “équilibré” utilisant une énumération rapide:

 [arr enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) { // do something with objects }]; [dict enumerateKeysAndObjectsUsingBlock:^(id key, id obj, BOOL *stop) { // do something with objects }]; 

J’essaie de faire un petit test pour voir si l’écart de performance est si grand pour la lecture et l’écriture entre NSArray et NSDictionary ainsi que leurs coutnerparts mutables …

Pourquoi? Si c’est juste pour satisfaire votre curiosité, c’est une chose. Mais généralement, si vous avez besoin d’un dictionnaire, un tableau ne fera pas l’affaire, et vice versa. Ainsi, peu importe laquelle est la plus rapide pour une opération donnée – ce n’est pas comme si l’une était une bonne alternative à l’autre.

Cependant, j’ai du mal à trouver un test “équilibré” … car le dictionnaire contient 2 objects (ou 3 selon votre perception) à boucler pour obtenir la valeur (et non la clé) recherchée, alors que le tableau n’a que un…

Vous faites ici des hypothèses qui ne sont probablement pas valables. Il n’ya probablement pas beaucoup de boucle pour accéder aux éléments de chaque type de conteneur.