Dev Faq
8
votes

'Règle d'un pouce' pour le coût de l'impression

J'ai remarqué que 

int i=10000000;
boolean isPrime= false;
      while(!isPrime){
           i++;
           System.out.println(item); //this kills performance
           isPrime = checkIfPrime(i);

     }
}

3 commentaires

Votre coût repousse les données sur le terminal (à la couche d'interface utilisateur) qui ralentit les choses, c'est le cou de la bouteille

Oui. Ma question est - quelles sont les astuces pour fournir des données, mais pas ralentir les choses? Je veux avoir une sortie, mais je ne veux pas ralentir considérablement les choses? Quel serait le coût de dire "s'il s'agit de la 100e tentative d'impression" vs "imprimer à chaque fois"?

J'ai écrit l'exemple de calcul dans ma réponse. Si vous aimez ma réponse, vous pouvez accepter, sinon faites-moi savoir si vous avez besoin de plus d'explications.

7 Réponses :

3
votes

Oui, l'impression est chère. Un processeur peut faire des millions d'opérations dans la période de temps nécessaire pour imprimer au terminal / IDE. Si vous utilisez Eclipse ou terminal, cela prend beaucoup de temps. Si vous utilisez un terminal, vous devez la rediriger vers un fichier à l'aide d'un fichier >> ou > ou écrivez-le dans un fichier à l'aide de nio ou < Code> io bibliothèque. Imprimer quelque chose que si son inévitable, sinon je sens que vous ne devez jamais imprimer si la performance est un problème.

3 commentaires

En outre, en utilisant 'system.out' pour la journalisation est une très mauvaise idée de toute façon.

Oui je sais. Mais si l'impression est inévitable, il s'agit d'une meilleure option que d'impression au terminal / IDE. Je ne sais pas pourquoi il veut imprimer.

Donc, cela signifie que la rédaction d'un fichier est moins chère que system.out.print ()? Comment?

7
votes

Comment comparer le coût de l'impression à l'écran sur calcul?

Ce n'est pas possible. Le coût (c'est-à-dire temps écoulé) de l'impression dépend de l'endroit où se passe les caractères «imprimés». Je peux trivialement construire un exemple où le coût a tendance à l'infini. xxx

après quelques lignes de sortie, les tampons de pipeline rempliront et le Imprimer Les appels dans votre application bloqueront.

Y a-t-il des astuces pour minimiser ce coût [Devrais-je imprimer un des 10 enregistrements sur 10, ou cela coûtera-t-il autant à cause de la vérification conditionnelle]?

Il n'y a rien qui ne présentera pas une autre surcharge; par exemple. la surcharge de tester s'il faut imprimer ou non.

Le seul moyen d'éliminer entièrement la surcharge d'impression est de pas d'imprimer du tout pendant que vous essayez de mesurer les performances.

Quelle est ma meilleure façon de procéder? Imprimer chaque cas? - Trop lent. Laissez-le courir pendant la nuit? Et si je manquais quelque chose de je ++?

exécutoire d'abord le programme avec les instructions d'impression pour vérifier que vous obtenez les bonnes réponses.

supprimez ensuite les instructions d'impression et exécutez à nouveau pour obtenir vos mesures de performance.

Cependant:

  1. méfiez-vous des différents pièges en écriture de micro-repères Java.
  2. Trawling via des pages et des pages d'impressions de trace n'est pas un bon moyen de vérifier les défauts (possibles) de votre programme.
4 commentaires

En supposant que je ne fais pas ce genre d'erreurs. Quel est le rapport entre le coût de "condition de test (divisible par 1000)" vs "imprimer chacun"? Existe-t-il un moyen cru à imprimer chaque nième résultat à un faible coût (mieux que "Imprimer si ce numéro est divisible par N")?

1) C'est (c (test) + 0,001 * C (impression)) / c (impression) . Évidemment, c (impression) doit être mesuré pour la manière dont les caractères imprimés sont manipulés. 2) non

"En supposant que je ne fais pas ce genre d'erreurs." - Je ne parlais pas d'une erreur. Mon exemple était de souligner que c'est impossible de donner une estimation significative pour le coût de l'impression.

@sixtytrees Ctrl / s est un autre exemple. Le coût devient infini. Ce que vous demandez est impossible en principe.

2
votes

Suivant est le plus rapide que vous puissiez faire pour calculer le prochain Prime et imprimer également tous ces chiffres que vous avez testés dans le processus (à condition que le prochain prime ne provoque pas trop débordement de INT): 

int i = 10000000;
boolean isPrime = false;
while (!isPrime) {
    i++;
    // System.out.println(item); //this kills performance
    isPrime = checkIfPrime(i);
}
for (int j = 10000001; j <= i; j++) sysout(j);

0 commentaires
2
votes

Si vous devez comparer vos performances de code, vous ne pouvez pas avoir des déclarations d'impression. Pour quelques itérations, vous devez imprimer, votre débogage et supprimer les instructions d'impression une fois que vous savez que votre code fonctionne correctement. Et puis effectuez la mesure de temps de votre code.
Sinon, si vous souhaitez avoir des déclarations d'impression toujours dans votre code, il vous suffit de décider de la quantité de retard que vous pouvez accepter. Par exemple, un processeur Xeon peut vous donner 28-35 gflops / iops (opérations par seconde), ce qui signifie que le processeur peut effectuer 35 * 10 ^ 9 des opérations d'incrément par seconde (il peut faire i ++ pour 35 * 10 ^ 9 fois / sec). et selon ceci ( https://stackoverflow.com/a/20683422/3409405 ) Réponse System.out.println ( ) Prend environ 1 ms. Donc, cela signifie que si vous imprimez pour chaque 10 ^ 6 i ++ Votre temps consommé sera doublé.

0 commentaires
1
votes

Comment comparer le coût de l'impression à l'écran sur calcul?

En mesurant: Mise en œuvre à la fois des approches (imprimez toutes les lignes, imprimez toutes les lignes X) et voyez laquelle est plus rapide et continuez à régler X pour un compromis raisonnable entre les mises à jour de statut fréquentes et le débit.

Il est important de noter que le coût de l'impression est fortement affecté par ce que vous imprimez. Le flux est-il tamponné ou rincez-vous chaque numéro? Est-ce qu'il écrit à la mémoire, à un SSD, à un disque dur ordinaire ou à un lecteur attaché à un port lent USB 1? Cela peut changer de performance d'écriture d'un facteur de 1000, c'est pourquoi vous devez mesurer votre cas d'utilisation particulière.

0 commentaires
1
votes

Une approche à cela pourrait être la suivante:

Effectuez votre tâche dans un thread, qui met à jour un tampon commun (String? Instance d'une classe d'informations?) Avec des trucs que vous souhaitez produire, mais n'effectuez pas la sortie réelle dans ce fil. L'esprit verrouille ce tampon afin que vous puissiez accéder à ces informations en toute sécurité de différents threads.

Ensuite, laissez une minuterie / un autre thread accédant à ce tampon commun pour imprimer ces informations. De cette façon, vous découplez le calcul de la sortie. L'inconvénient est que vous ne verrez pas chaque sortie , mais alors que la sortie est générée, le calcul continue.

0 commentaires
1
votes

Une réponse courte est la suivante: cela dépend vraiment. Le texte d'impression est coûteux. Cent "impression i" est beaucoup plus chère que la chaîne de construction avec un stringbuilder et le tir "Imprimer" une fois.

0 commentaires

Articles qui pourrait vous intéresser :

Comment envoyer une liste vide à la clause IN
Code de réponse 403 inattendu lors de la récupération des données des API
Impossible de trouver la classe UnityPlayerActivity dans com.unity3d.player
Comment définir un tableau dans jsonobject