web-dev-qa-db-fra.com

Pourquoi l'impression "B" est-elle considérablement plus lente que l'impression "#"?

J'ai généré deux matrices de 1000 x 1000:

Première matrice: O et #.
Deuxième matrice: O et B.

À l'aide du code suivant, la première matrice a duré 8,52 secondes:

Random r = new Random();
for (int i = 0; i < 1000; i++) {
    for (int j = 0; j < 1000; j++) {
        if(r.nextInt(4) == 0) {
            System.out.print("O");
        } else {
            System.out.print("#");
        }
    }

   System.out.println("");
 }

Avec ce code, il a fallu 259,152 secondes pour compléter la seconde matrice:

Random r = new Random();
for (int i = 0; i < 1000; i++) {
    for (int j = 0; j < 1000; j++) {
        if(r.nextInt(4) == 0) {
            System.out.print("O");
        } else {
            System.out.print("B"); //only line changed
        }
    }

    System.out.println("");
}

Quelle est la raison derrière les temps d'exécution radicalement différents?

Comme suggéré dans les commentaires, imprimer uniquement System.out.print("#"); prend 7.8871 secondes, alors que System.out.print("B"); donne still printing....

Comme d'autres qui ont fait remarquer que cela fonctionne normalement pour eux, j'ai essayé Ideone.com , par exemple, et les deux morceaux de code s'exécutent à la même vitesse.

Conditions de test:

  • J'ai exécuté ce test à partir de Netbeans 7.2 , avec la sortie dans sa console.
  • J'ai utilisé System.nanoTime() pour les mesures
javaperformanceloopsfor-loopsystem.out
2629
Kuba Spatny

La pure spéculation est que vous utilisez un terminal qui tente de faire le retour à la ligne plutôt que le retour à la ligne, et traite B en tant que caractère Word mais # en tant que caractère autre que Word. Donc, quand il atteint la fin d'une ligne et cherche un endroit pour la casser, il voit un # presque immédiatement et heureusement s'y brise; alors qu'avec B, il doit continuer à chercher plus longtemps et peut avoir plus de texte à envelopper (ce qui peut coûter cher sur certains terminaux, par exemple, la sortie d'espaces de fond, puis l'affichage d'espaces pour écraser les lettres qui sont enveloppées).

Mais ce n'est que pure spéculation.

3959
T.J. Crowder

J'ai effectué des tests sur Eclipse vs Netbeans 8.0.2, tous deux avec Java version 1.8; J'ai utilisé System.nanoTime() pour les mesures.

Éclipse:

J'ai eu le même temps sur les deux cas - environ 1,564 secondes .

Netbeans:

  • Utilisation de "#": 1,536 secondes
  • Utilisation de "B": 44,164 secondes

Il semble donc que Netbeans ait de mauvaises performances lors de l’impression sur la console.

Après plus de recherches, j'ai réalisé que le problème est retour à la ligne de la mémoire tampon maximale de Netbeans (ce n'est pas limité à la commande System.out.println, commande), illustrée par ce code:

for (int i = 0; i < 1000; i++) {
    long t1 = System.nanoTime();
    System.out.print("BBB......BBB"); \\<-contain 1000 "B"
    long t2 = System.nanoTime();
    System.out.println(t2-t1);
    System.out.println("");
}

Les résultats temporels sont inférieurs à 1 milliseconde à chaque itération, sauf à chaque cinquième itération , lorsque le résultat temporel est d'environ 225 millisecondes. Quelque chose comme (en nanosecondes):

BBB...31744
BBB...31744
BBB...31744
BBB...31744
BBB...226365807
BBB...31744
BBB...31744
BBB...31744
BBB...31744
BBB...226365807
.
.
.

Etc..

Sommaire:

  1. Eclipse fonctionne parfaitement avec "B"
  2. Netbeans a un problème de retour à la ligne qui peut être résolu (car le problème ne se produit pas dans Eclipse) (sans ajouter d'espace après B ("B")).
186
Roy Shmuli