J'ai une fonction qui nécessite un stockage temporaire interne pour ses calculs (certaines opérations matricielles) et je sais que cette fonction sera appelée fréquemment (disons chaque milliseconde tout au long du temps d'exécution du programme). Mon sentiment d'intestin me dit qu'il est préférable de déclarer ces variables temporaires statiques, il n'y a donc pas tant d'efforts administratifs pour les créer à nouveau et à nouveau avec chaque appel de la fonction. Je dois les initialiser de toute façon chaque fois que la fonction est appelée, alors les garder en vie n'est pas nécessaire à des fins fonctionnelles. Je suis conscient que les faire des pauses statiques de la sécurité thread-sécurité, mais ce n'est pas un problème ici.
Comme la connaissance est généralement meilleure que tout sentiment intestinal, j'aimerais savoir ce que le «correct» de manipuler ce cas est . ou
8 Réponses :
Il n'y a pas de différence. Il n'y a aucun code nécessaire pour "créer" un tableau non initialisé.
Dans le cas d'une matrice statique, la mémoire est réservée et disponible tout le temps. Dans le cas d'une matrice automatique, il est sur la pile, et tout ce qui est nécessaire pour "créer", il est de déplacer le pointeur de pile, ce qui va se passer de toute façon à l'entrée de la fonction.
(et un jour, vous allez essayer d'utiliser cette fonction dans un programme multithreadé et la version statique subira des échecs intermittents occasionnels qui vous poussent à boire et à droguer. Il ne vaut tout simplement pas le risque.)
Il peut ne pas y avoir de frais généraux pour créer les variables locales, mais ils devront être consultés par rapport à un pointeur de pile ou de base, il pourrait donc y avoir une performance mesurable.
@Christoph: point intéressant. Je me demande si cela fait une différence sur un processeur moderne? Je parie que ça ne le fait pas, mais je ne suis pas un assistant de montage. :-)
J'essaie de penser à une plate-forme que ce serait un problème. Étant donné qu'il sera fixé à partir du cadre de pile donné, cela ne devrait pas causer de problème. Par exemple sur MIPS, vous pouvez faire un LD R1, Frame_Offset (Stack_Frame_Base) afin que ce soit gratuit. MOV EAX, [ESP + FRAMD_OFFSET] est gratuit aussi ...
Notez également que même dans le cas d'une variable statique, les diverses accessoires de réseau devront également se produire via une indirection d'un registre en raison des opérations d'index du pointeur / de matrice qui se dérouleront. Donc, il n'y a même pas vraiment un avantage théorique à une variable statique ici.
Le seul moyen de savoir est d'essayer et de le tester. Il est peu probable de faire beaucoup de différence, cependant.
Vous essayez une micro-optimisation sans comparaison comparative, ce qui est généralement considéré comme une mauvaise chose. Vous devriez toujours comparer la référence. Sinon, comment saurez-vous certainement que toute tentative d'optimisation fonctionnait?
Il est peu probable que vous obtiendrez quelque chose de cela, et la lisibilité et la maintenance de codes devraient être en premier.
Comme d'habitude, vous devriez être profilé en premier. Les variables locales ne font probablement que décrémenter le pointeur de la pile un peu plus qui ne devrait pas avoir de pénalité de performance.
Je voudrais certainement l'écrire la manière la plus simple et la plus lisible en premier. Une fois par milliseconde sonne comme une fonction très rarement la fonction de micro-optimisation.
Une fois que vous l'avez travaillé, ça repère. Décidez si la performance est suffisamment bonne. Si ce n'est pas l'optimisation et la référence. Ne faites pas Nettoyez le code de nettoyage hors de forme sans chiffres très solides pour sauvegarder votre décision.
Allocation de variables de pile ne peut pas affecter des variables de tas tout ce qui se passe est que le pointeur de pile est déplacé suffisamment loin pour allouer toute la mémoire nécessaire par la fonction. Il n'y a pas de frais généraux dans l'attribution d'une ou cent variables dans un cadre de pile. Le pointeur de pile va déjà être déplacé lorsque la fonction est appelée même s'il ya zéro variables (pour enregistrer où revenir à etc.)
réservation d'espace pour variables avec durée de stockage automatique signifie simplement diminuer le pointeur de la pile, de sorte que ce ne sont pas les seules variables locales, il n'y a pas de frais généraux.
Qu'est-ce qui pourrait faire mal aux performances, que les variables allouées de la pile doivent être adressées par rapport à un pointeur de pile ou de base, afin d'utiliser comme toujours, comparez le code pour vous assurer. statique pourraient légèrement améliorer les performances.
sur SPARC surtout en mode 64 bits, le cas statique est plus lent. L'accès à une variable globale (que la statique est, ce n'est que le nom limité au champ d'application de la fonction) nécessite 5 instructions à l'aide de 3 enregistrements, dans votre cas 10 instructions uniquement pour obtenir l'adresse des tableaux. La version non statique, comme il a déjà été signalé, n'a pas de surcharge, car le cadre est construit en anycarbure, si le pointeur de pile augmente 16 octets ou 200 ne fait aucune différence. Mais soyez prudent si vous initiez votre tableau, cela peut générer un memsse caché pouvant être coûteux.
void frequentlyCalledFunction(void)
{
double matrix1[10][10]={0.0};
double matrix2[10][10]={0.0};
/* do something with the matrices ... */
}