Le code C est-il plus rapide?

L’appel de code C à partir d’Objective-C présente-t-il un gain de performance?

J’ai lu quelque part que la transmission des messages est plus lente que celle des autres langages utilisant l’appel de fonction. Donc, si j’appelle une fonction C à partir de code Objective-C, est-ce que j’évite les frais de messagerie?

Lors de l’optimisation des performances, est-il recommandé de coder les fonctions et les procédures les plus critiques en C au lieu d’utiliser des objects Objective-C?

MODIFIER:
Compte tenu du nombre de réponses mettant en garde sur l’optimisation prématurée et la lisibilité du code, je tiens à préciser que je ne pensais pas aux applications classiques, mais à des applications très spécifiques telles que:

  • Graphique
  • Cryptage ou algorithmes de compression.
  • Mathématiques

Et en général, les fonctions ou procédures qui ne nécessitent pas de conception OO et qui doivent être appelées plusieurs fois avec des parameters.

Il s’agit d’une référence qui compare la messagerie aux fonctions C appelantes. Voici les résultats de l’appel de différentes implémentations de la fonction fibonacci environ 1,4 milliard de fois.

Message Passing 23.495 seconds IMP Calling 16.033 seconds C Function 9.709 seconds 

Donc, oui, il y a une surcharge lors de l’appel d’une méthode Objective C. Mais, sauf dans certaines situations, ce n’est pas ce qui affectera les performances de votre application. En fait, la messagerie est toujours plus efficace que la plupart des autres opérations telles que la division en virgule flottante.

En outre, la plupart des applications passent le plus clair de leur temps à attendre l’entrée de l’utilisateur, le téléchargement de données, etc.

Il est très peu probable que vous écriviez du code suffisamment optimisé pour que le goulot d’étranglement soit un envoi de message. Écrivez votre code de la manière qui vous convient le mieux, puis utilisez Instruments pour profiler et optimiser si nécessaire . Il est presque certain que si votre code est lent, cela sera dû à des problèmes beaucoup plus graves que l’envoi de messages.

Oui, il est recommandé d’utiliser un langage C ordinaire bien écrit au lieu d’utiliser Objective C à l’intérieur de boucles internes de performances critiques, telles que le traitement du signal audio en temps réel ou le code de traitement d’image. L’utilisation de types de données d’object ou de messagerie présente rarement des avantages lorsque vous utilisez des milliers d’échantillons audio individuels, ou des millions de pixels d’image, par trame. Tous les cycles d’envoi de méthodes inutiles ne font que gaspiller la vie de la batterie des utilisateurs. D’autres types de simulations numériques complexes et de modèles par éléments finis (etc.) pourraient également bénéficier de la simplicité de la boucle interne pour de meilleurs résultats avec l’optimiseur du compilateur.

Cependant, les contenus de niveau supérieur qui ne doivent se produire que quelques fois par événement à un rythme humain ne consumnt probablement pas assez de messages pour que les cycles de temps système soient mesurables. Par conséquent, toute abstraction visant à améliorer la lisibilité du code et sa réutilisation ici ne risque pas de coûter à l’utilisateur de performance ou d’autonomie de la batterie.

L’appel direct à une fonction C sera toujours plus rapide que d’appeler une méthode Obj-C; mais, comme beaucoup l’ont souligné, il est peu probable que le code soit gênant, à l’exception du code sensible aux performances.

Cependant, vous pouvez inverser la situation et demander pourquoi utiliser une méthode si elle est plus lente. – l’édit contre “l’optimisation prématurée” ne signifie pas “écrire express un code de mauvaise qualité”.

C’est un équilibre et la frontière entre l’utilisation d’une méthode ou d’une fonction est floue, vous devez faire le choix. Deux parameters pouvant aider:

  1. Si le code va modifier l’état de l’object, utilisez une méthode.
  2. Si le code est une fonction naturelle; prend des entrées, produit une sortie, ne manipule pas d’état (a des “effets secondaires”); alors une fonction a un sens.

Pour tous les points intermédiaires, utilisez votre propre jugement.

Par exemple, si vous avez un code dans une classe qui a besoin de calculer le volume d’une pyramide à plusieurs endroits, vous résumez l’algorithme de volume: méthode ou fonction? Fonction – il prend des valeurs, produit une valeur, ne modifie pas l’état de l’object. Il est peut-être même préférable d’en faire une fonction static , ce qui la rend réellement privée à la classe et ne pollue pas l’espace de noms de vos applications. Écrire un tel algorithme en tant que méthode si elle n’est utilisée qu’en interne par la classe n’a aucun intérêt – je dirais que c’était du “mauvais code” pour le faire (mais c’est un avis !)

Un message initial est interprété au moment de l’exécution et, en tant que tel, prend environ trois fois plus de temps qu’un appel de méthode virtuelle C ++ (ce qui est légèrement plus lent qu’un appel direct). Cependant, les appels suivants sont mis en cache avec IMP et dans la plupart des implémentations, ils sont donc plus rapides qu’un appel de méthode virtuelle C ++, mais toujours légèrement plus lentement qu’un appel de fonction direct (en C ou C ++).

Donc, oui, il peut y avoir un gain de performance, mais avant de perdre tous les avantages d’Objective-C, vous devez être sûr que l’avantage de “l’optimisation” est significatif. Dans la plupart des cas, de meilleures performances peuvent être obtenues ailleurs. en employant des structures de données et des algorithmes appropriés, par exemple. La plupart du code passe son temps à faire des choses plutôt que dans le temps système d’appel de fonction – YMMV.

Voir le mécanisme d’envoi de messages Objective C