ce qui est moins gourmand en ressources : Liaisons, KVO, ou Notifications

Question

Plutôt que d'essayer d'exécuter un tas de tests. Quelqu'un sait-il ce qui est moins gourmand en ressources ?

Fixations, KVO ou Notifications ? Quelqu'un a-t-il testé pour voir aussi ?

Answer 1

Sous OS X, cela n'a généralement pas d'importance. Ils sont tous légers. Apple lui-même s'y fie, et les implémentations sont donc hautement optimisées. J'écrirais le code de manière à ce qu'il soit aussi lisible que possible, et n'optimiserais la vitesse et la consommation de ressources que lorsque c'est nécessaire.

Un autre point est qu'Apple modifie souvent l'implémentation d'une version à l'autre du système d'exploitation. Ainsi, le coût relatif (vitesse, consommation de ressources, etc.) de diverses technologies particulières change souvent. Ce que l'on peut trouver sur le net est souvent dépassé. Apple elle-même insiste sur le fait qu'il ne faut jamais présumer de ce qui est plus rapide et plus léger, et qu'il faut plutôt utiliser un profileur (Instruments, etc.) pour mesurer soi-même le goulot d'étranglement.

Answer 2

La réponse de Chuck est tout à fait correcte en ce qui concerne les notifications par rapport à la KVO, mais j'aimerais développer le point "Les fixations sont KVO +". KVC + ..." qu'il a mentionné parce que c'est là que se trouve le véritable casse-tête. Le codage par valeur de clé semble être la considération la plus importante ici, puisque vous ne pouvez pas utiliser les liaisons sans lui. Si vous vous préoccupez des performances pour de bonnes raisons, vous feriez bien de noter le coût que peut entraîner une utilisation intensive du KVC.

Je dirais que toute circonstance qui nécessite une interrogation importante à la suite d'une seule action (par exemple, demander à quelques milliers d'objets les résultats de plusieurs chemins clés chacun) serait un indicateur que vous pourriez vouloir éviter le KVC (et les Bindings par extension). En particulier avec des chemins de clés longs ( -valueForKeyPath : vs. -valueForKey : ).

Je me suis moi-même heurté à ce problème et je m'efforce maintenant d'éliminer cette partie de mon architecture. Le coût relativement minime du Key Value Coding peut sérieusement s'accumuler lorsque vous demandez à 16 000 objets le résultat d'une demi-douzaine de longs chemins de touches à la suite d'une pression sur un bouton (même avec NSOperation/Queueue). La différence entre l'utilisation de KVC et les bons vieux appels [[message d'objet] message...] peut faire la différence entre quelques secondes et bien plus d'une minute ou deux sur des travaux importants. Pour moi, la même requête qui appelait directement les accesseurs (comme [nom du paramètre] ou [[nom de la variable du paramètre]]) représentait une augmentation d'environ 500 % de la vitesse. Il est vrai que mon modèle de données est assez complexe et que le volume de données d'un document type est important.

D'un autre côté, si de nombreuses actions uniques de votre application affectent/interrogent un ou quelques objets et sont principalement orientées vers l'observation de valeurs clés (par exemple, changer un nom de famille et le mettre à jour dans plusieurs vues à la fois), sa simplicité peut relever de la magie.

En résumé, si votre application interroge/met à jour de gros volumes de données, vous feriez mieux d'éviter KVC et Bindings pour la partie interrogation/mise à jour pour les raisons suivantes KVC et non à cause de KVO .

Answer 3

Ce ne sont pas vraiment des options distinctes, en soi. KVO est un cas particulier de notifications. Les liaisons sont KVO + KVC + quelques classes de colle.