Plutôt que d'essayer d'exécuter un tas de tests. Est-ce que quelqu'un sait ce qui nécessite moins de ressources?Moins gourmand en ressources: Liaisons, KVO ou Notifications
Liaisons, KVO ou notifications? Quelqu'un at-il testé pour voir aussi bien?
La réponse de Chuck est tout à fait raison dans la mesure où les notifications par rapport à KVO va, mais je voudrais développer la partie, il a mentionné « consolidations sont KVO + KVC + ... » parce que la douleur est là réel le cul peut être. Key Value Coding semble être la considération la plus importante ici, car vous ne pouvez pas utiliser les liaisons sans cela. Si vous vous inquiétez de la performance pour de bonnes raisons, vous ferez bien de noter que l'utilisation intensive de KVC peut entraîner des coûts.
Je dirais que toutes les circonstances qui nécessitent une requête lourde à la suite d'une seule action (exemple: demander quelques milliers d'objets pour les résultats de plusieurs chemins clés chacun) serait un indicateur que vous pourriez vouloir éviter KVC (et liaisons par extension). Spécialement avec des chemins de clé longs (-valueForKeyPath: vs -valueForKey:).
Je me suis lancé à fond contre ce problème et je travaille maintenant à l'élimination de cette partie de mon architecture. Le coût relativement minime du codage de valeur clé peut sérieusement augmenter lorsque vous demandez à 16 000 objets le résultat d'une demi-douzaine de chemins de clé longs suite à une pression sur un bouton (même avec NSOperation/Queue). La différence entre l'utilisation de KVC et les appels [[message d'objet] ...] peut signifier la différence entre quelques secondes et bien plus d'une minute ou deux sur les gros travaux. Pour moi, la même requête appelant directement les accesseurs (comme [nom du paramètre] ou [[paramètre variable] nom]) représentait à peu près une augmentation de 500% de la vitesse. Certes, le mien est un modèle de données assez complexe avec un grand volume de données pour un document typique. D'autre part, si de nombreuses actions individuelles de votre application affectent/interrogent un ou plusieurs objets et sont principalement axées sur les valeurs clés (par exemple, changer un nom de famille et le mettre à jour dans plusieurs vues à la fois), sa simplicité peut s'apparenter à de la magie.
En résumé: si vos requêtes d'applications/mises à jour de gros volumes de données, vous pouvez faire mieux pour éviter KVC et fixations pour la partie requête/mise à jour en raison de KVC, non pas à cause de KVO.
Sous OS X, cela n'a généralement pas d'importance. Ils sont tous légers. Apple lui-même en dépend, et les implémentations sont hautement optimisées. J'écrirais le code de manière à ce qu'il soit aussi lisible que possible, et j'optimiserais seulement la consommation de vitesse/ressource quand c'est nécessaire. Un autre point est que Apple modifie souvent l'implémentation à travers la version du système d'exploitation. Ainsi, le coût relatif (vitesse, consommation de ressources, etc.) de diverses technologies particulières change souvent. Ce qui peut être trouvé sur le net peut être souvent obsolète. Apple lui-même insiste pour ne jamais supposer qui est plus rapide et plus léger, et au lieu d'utiliser profiler (Instruments, etc.) pour mesurer le goulot d'étranglement vous-même.
Ce ne sont pas des options vraiment distinctes, en soi. KVO est un cas particulier de notifications. Les liaisons sont KVO + KVC + quelques classes de colle.