Performances du tableau vide Objective-C

Question

J'ai une application qui itère sur un tableau à chaque pas et il me semble obtenir des résultats étonnamment lents quand le tableau est vide. Donc, j'ai enquêté avec des tests de suivi qui sont allés quelque chose comme ça:

NSMutableArray* ar = [NSMutableArray array]; 
double time = CFAbsoluteTimeGetCurrent(); 
for (int i = 0; i < 10000; i++) 
{ 
    for (NSObject* obj in ar) 
    { 
     [obj retain]; 
     [obj release]; 
    } 
} 
time = CFAbsoluteTimeGetCurrent() - time; 
printf("Empty Time: %1.12f", time/10000.0f); 

time = CFAbsoluteTimeGetCurrent(); 
for (int i = 0; i < 10000; i++) 
{ 
    if ([ar count] > 0) 
    { 
     for (NSObject* obj in ar) 
     { 
      [obj retain]; 
      [obj release]; 
     } 
    } 
} 
time = CFAbsoluteTimeGetCurrent() - time; 
printf("Checked Time: %1.12f", time/10000.0f); 

J'ai essayé ceci pour 100 | 1,000 | 10.000 itérations intervalles avec les résultats suivants:

Empty Time: 0.000000039935   //100 
Checked Time: 0.000000020266  //100 
Empty Time: 0.000000018001   //1000 
Checked Time: 0.000000011027  //1000 
Empty Time: 0.000000015503   //10000 
Checked Time: 0.000000008899  //10000 

Étrangement, cela montre que le comte ayant simplement vérifier améliore considérablement les performances sur les pistes à faible itération (probablement à cause des systèmes de mise en cache). Ceci est absolument étonnant pour moi car je m'attendais à ce que la compilation/exécution d'Objective-C fasse déjà ce contrôle chaque fois qu'une boucle foreach est exécutée! Est-ce que quelqu'un a une idée de ce que cela pourrait être le cas et s'il y a un moyen de tirer encore plus de performance de cette configuration en boucle? Merci!

Answer 1

Les tableaux vides ne sont pas très courants dans un programme Cocoa typique, pas plus que l'itération d'un tableau vide de dizaines de milliers de fois.

Il serait exceptionnellement surprenant de voir jamais l'énumération des tableaux vides apparaître dans les Instruments en tant que consommateur important de cycles CPU. Etant donné que la Fondation et la Fondation de base sont optimisées pour les modèles de performance du monde réel, il n'est pas surprenant qu'aucune vérification du nombre de 0 ne soit effectuée.

Toutefois, si vous avez vraiment devez itérer un tableau vide une fois bazillion, le meilleur moyen est d'utiliser un bloc:

time = CFAbsoluteTimeGetCurrent(); 
[ar enumerateObjectsUsingBlock:^(id obj, NSUInteger idx, BOOL *stop) { 
    [obj retain]; 
    [obj release]; 
}]; 

Je collais votre code en principal de l'outil Fondation() et a ceci sur un relativement récent MacBook Pro:

 Empty Time: 0.000000019896 
    Checked Time: 0.000000007498 
    Block Time: 0.000000000298 

---

Bien sûr, au lieu de tableaux vides, il suffit d'utiliser nil. C'est à dire. J'ai fait tous les tests une deuxième fois après ar = nil;.

ar = nil; 
time = CFAbsoluteTimeGetCurrent(); 
for (int i = 0; i < 10000; i++) 
{ 
    for (NSObject* obj in ar) 
    { 
     [obj retain]; 
     [obj release]; 
    } 
} 
... etc ... 


     Empty Time: 0.000000019902 
    Checked Time: 0.000000007999 
     Block Time: 0.000000000298 
    nil Empty Time: 0.000000015599 
nil Checked Time: 0.000000004703 
    nil Block Time: 0.000000000000 

---

Dans l'ensemble, cependant, si vos structures de données sont que complexes et vous martèlent sur eux beaucoup sur chaque image render, je vous suggère une structure de données différentes peut-être dans l'ordre.

Bien sûr, uniquement si vous avez réellement utilisé des instruments pour échantillonner le code et que vous optimisez quelque chose qui consomme un pourcentage significatif de cycles CPU globaux.

Answer 2

La construction for-in n'est pas libre, elle doit être résolue en une sorte d'appel de méthode d'énumération, de sorte que les temps indiqués ont du sens. J'utiliserais un tableau C simple dans ce cas. De plus, vous obtiendrez de meilleures performances si vous utilisez objc_msgsend() pour appeler des méthodes objc dans de telles grandes boucles.