Chaque fois que vous appelez une fonction avec des paramètres, vous copiez les valeurs des paramètres. Dans vos exemples, il s'agit simplement de savoir si vous copiez des valeurs de pointeur ou des valeurs entières. La copie d'un int ne sera pas sensiblement plus rapide ou plus lente que la copie d'un pointeur, mais avec un pointeur, vous avez une lecture supplémentaire de la mémoire chaque fois que vous déréférencer le pointeur.

Pour tout type de données simple, il vaut mieux accepter les paramètres par valeur. Le seul moment où il est plus logique de passer un pointeur est si vous avez affaire à un tableau ou une struct qui peut être arbitrairement grand.

ce qui signifie qu'il est plus lent en termes de performances que de passer des pointeurs

C'est là que vous vous êtes trompé. Sur un ordinateur 32 bits typique, int est 32 bits et les pointeurs sont 32 bits. Ainsi, la quantité réelle de données transmises est identique entre les deux versions. Cependant, l'utilisation de pointeurs peut se résumer à un code machine à accès indirect, donc il peut en fait produire du code moins inefficace dans certaines circonstances. Dans le cas général, int add (int a, int b) est probablement le plus efficace.

En règle générale, il est correct de passer tous les types entiers et flottants standard par valeur aux fonctions. Mais les structures ou unions doivent être passées par des pointeurs.

Dans ce cas particulier, le compilateur est susceptible de "incorporer" toute la fonction, en la remplaçant par une seule instruction d'ajout dans le code machine. Après quoi, tout le paramètre passant se transforme en un non-problème.

Dans l'ensemble, ne réfléchissez pas trop aux performances en tant que débutant, c'est un sujet avancé et dépend du système spécifique. Au lieu de cela, concentrez-vous sur l'écriture de code aussi lisible que possible.

De mon point de vue, selon que vous avez un compilateur capable de développer des fonctions en ligne , le moyen le plus rapide de le faire est simplement:

    .file   "inline.c"
    .globl  main                    @ -- Begin function main
    .p2align        2
    .type   main,%function
    .code   32                      @ @main
main:
    .fnstart
@ %bb.0:
    .save   {r11, lr}
    push    {r11, lr}
    .setfp  r11, sp
    mov     r11, sp
    mov     r0, #3
    mov     r1, #2
    bl      sum                 <--- the call to the function.
    mov     r0, #0
    pop     {r11, pc}
.Lfunc_end0:
    .size   main, .Lfunc_end0-main
    .cantunwind
    .fnend

car le compilateur évitera probablement le plus souvent l'appel / le retour du sous-programme et utilisera la meilleure extension disponible dans chaque cas d'utilisation (dans la plupart des cas, cela sera intégré comme une seule instruction add r3, r8 . ) Cela peut prendre bien moins qu'un seul cycle d'horloge dans de nombreux processeurs multicœurs et pipelined d'aujourd'hui.

Si vous n'avez pas accès à un tel compilateur, alors probablement la meilleure façon de simuler ce scénario consiste à:

int add(int a, int b);

int main()
{
    int a = 3, b = 2, c = sum(a, b);
}

et vous serez en ligne, tout en conservant la notation de la fonction. Mais les locaux échouent avec cette réponse, car vous avez demandé une fonction, en fonction de la priorité des locaux :)

Lorsque vous pensez à la meilleure façon de faire un appel de fonction, pensez d'abord que, pour les petits fonctions, la tâche la plus lourde que vous faites est de faire un appel de sous-programme du tout ... comme il faut du temps pour pousser l'adresse de retour, pensez que dans ce cas, le pire est de devoir appeler une fonction, juste pour ajouter deux paramètres (l'ajout de deux valeurs stockées dans les registres ne nécessite qu'une seule instruction, mais avec un appel de fonction, il en nécessite au moins trois --- l'appel, l'ajout et le retour) L'ajout ne demande pas beaucoup de temps si les addends sont déjà dans les registres, mais un appel de sous-programme nécessite normalement de pousser un registre dans la pile et de le faire apparaître plus tard. Ce sont deux accès mémoire, qui coûteront plus cher, même s'ils sont mis en cache dans le cache d'instructions.

Bien sûr, si le compilateur sait que la fonction peut être mise en cache, et que vous l'utilisez plusieurs fois avec les mêmes paramètres dans une expression ou dans le même bloc, il peut mettre en cache la valeur de résultat à utiliser plus tard, et économiser le coût de la reconstitution de la somme. La chose devient comme si la meilleure façon de procéder était de voir à quel scénario exact nous avons affaire. Mais à ce stade, le coût majeur de l'ajout de deux nombres, est de loin, le coût de l'enfermer dans une enveloppe de fonction.

EDIT

J'ai essayé l'exemple suivant et compilé il dans une architecture arm7 (raspberry pi B +, freebsd, compilateur clang) et le résultat était loin que bon :)

inline.c

    /* ... */
    .file   "inline.c"
    .globl  main                    @ -- Begin function main
    .p2align        2
    .type   main,%function
    .code   32                      @ @main
main:
    .fnstart
@ %bb.0:
    mov     r0, #0
    bx      lr
.Lfunc_end0:
    .size   main, .Lfunc_end0-main

résultant dans:

inline int sum(int a, int b)
{
    return a + b;
}

int main()
{
    int a = 3, b = 2, c = sum(a, b);
}

Comme vous le voyez, le seul code pour main consistait à stocker la valeur de retour 0 dans r0 (exit code);)

Juste au cas où je compilerais add comme une fonction de bibliothèque externe:

#define add(a,b) ((a) + (b))

donnerait:

inline int add(int a, int b)
{
    return a + b;
}

Vous pouvez voir que l'appel à la fonction sera fait, de toute façon, car le compilateur n'a pas été informé du type de fonction qu'il a sous la main (même si le résultat le code ne sera pas utilisé, car la fonction peut avoir des effets latéraux), et doit de toute façon être appelée.

Au fait, et comme mentionné, la manière de passer des références à une fonction implique un déréférencement ces pointeurs, et t hat signifie normalement des accès à la mémoire (ce qui est beaucoup plus cher que d'ajouter deux registres ensemble)