Normalement quand j'ai un grand pour la boucle, je mets des messages pour m'informer dans quelle partie du processus mon programme est, par exemple: Je me demandais si cela fait trop mal le Performance (a priori) et si c'est le cas s'il y a une alternative plus intelligente.Merci à l'avance. P> P>
6 Réponses :
Votre test MOD ne blesse probablement pas les performances, mais si vous voulez un test très rapide et que vous êtes prêt pour les multiples de deux, envisagez ensuite un test mathématique ou p> et code>:
C'est le printf qui utilise la CPU en haut, pas le si
@Ltworf pas toujours. Si vous codez une boucle très serrée qui effectue une simple arithmétique et qui tourne de manière incroyablement rapidement, le pourcentage de temps passé dans le si code> énoncé compte. Bien sûr, c'est un cas rare, mais lorsqu'il importe un peu de bashing peut aider. Bien qu'un imprimeur () prend beaucoup de temps, il devient négligeable s'il est appelé avec parcimonie dans la boucle - d'où le but du si code> appelez en premier lieu pour imprimer à l'occasion. Ainsi, alors que votre affirmation est généralement correcte, ce serait une erreur de faire un appel de couverture sans connaissance de ce que la boucle contient.
Peut-être que vous pouvez diviser la grande boucle afin de vérifier la condition parfois, mais je ne sais pas si cela permettra de gagner du temps, cela dépend plus de votre "autre chose".
int T = ...; // times to check the condition, make sure large_n % T == 0
for(int t = 0; t < T; ++t)
{
for(int i = large_n/T * t; i < large_n/T * (t+1); ++i)
{
// other stuff
}
printf("We are at %ld \n", large_n/T * (t+1));
}
Peu importe ce qui est dans votre boucle, je ne laisserais pas de laisser des déclarations telles que Ces deux sont des exemples de débogage de niveau de trace. Ils sont totalement valables et dans certains cas très utiles, mais généralement pas finalement, donc dans la demande finale. À cet égard, une chose habituelle à faire est de les inclure que dans la construction lorsque vous souhaitez utiliser les informations fournies. Dans ce cas, vous pourriez faire quelque chose comme ceci: p> concernant le coût de performance d'inclure ces sorties de débogage tout le temps, il dépendra totalement du système que vous utilisez. , l'efficacité de l'instruction "impression" que vous utilisez pour émettre les données, les check / s que vous effectuez et, bien sûr, quelle fréquence vous essayez d'effectuer une sortie. P> P> printf code> à moins que cela soit essentiel à l'application / utilisateur, pas plus que j'utilise ce qui sont effectivement redondants si < / code> déclarations, pour la même raison.
+1 Pour la mention de débogage, OP constaterait probablement utile qu'il puisse être défini avec le drapeau -DDEBUG = 1 CODE> COMPILATEUR, Grandly Aides Débogage.
En plaçant une instruction d'impression à l'intérieur de la boucle pour la boucle, vous sacrifiez des performances.
Parce que le programme doit apporter un appel système pour écrire une sortie à l'écran chaque fois que le message est imprimé, il prend le temps de processeur. du programme lui-même. p>
Vous pouvez voir la différence de performance entre ces deux boucles: P>
int i;
for(i = 0; i < 100000; i++) {
if(i%100 == 0)
printf("%d", i);
}
C'est à peu près ce que je fais. La question est plutôt que la déclaration "si" blesse la performance.
Le problème est l'opération IO printf code> prend beaucoup de temps que les calculs de processeur. Vous pouvez réduire le temps si vous pouvez les ajouter à tous et à imprimer enfin. P>
NOTATION:
id = progressRegister (<some predefined type of progress update mechanism>);
for(i = 0; i < large_n; i++) {
progressUpdate (id, <string>, i, large_n);
// Do some other stuff
}
progressUnregister(id);
Quoi qu'il en soit à la fin, vous le supprimez non?
Pourquoi faites-vous
/ 1000 code>? Je dirais quei% grand_n code> devrait suffire pour cela.Pourquoi vous souciez-vous de la performance pour quelque chose que vous utilisez uniquement dans les bâtiments de débogage et de développement?
Toujours
i% grand_n == i code>Les gars, la boucle va à
grand_n code>. La condition dans lesi code> doit êtrei% a_value_smaller_than_n == 0 code>, éventuellementgrand_n / 1000 code>.@Nikosc. Parce que cela prend beaucoup de temps (~ demi-journée). Toute heure enregistrée serait bien.
Si la boucle prend suffisamment longtemps pour exécuter que cette sortie est utile, elle n'aura pas d'impact significatif sur la performance. Si le code fonctionne si rapidement que cette sortie n'est pas nécessaire, l'impact sur le temps de traitement total peut être substantiel (ceci n'est pas probable), mais le temps de traitement total est négligeable, de sorte que la sortie est simplement ennuyeuse.
Vous voudrez peut-être utiliser
\ r code> au lieu de\ n code>.@Williampursell Quelle est la différence entre \ r et \ n?
@Williampursell ou plutôt pourquoi est préférable \ r?
@Bunder, essayez-le. Au lieu d'obtenir une nouvelle ligne pour chaque Printf, la nouvelle ligne écrasera la précédente.
@Williampursell jolie cool, merci!