2 Pytanie: Dlaczego drukowanie „B” jest znacznie wolniejsze niż drukowanie „#”?

pytanie utworzone w Fri, Apr 6, 2018 12:00 AM

Wygenerowałem dwie macierze 1000 x 1000:

Pierwsza macierz: O i #.
Druga macierz: O i B.

Używając następującego kodu, pierwsza matryca zajęła 8,52 sekundy, aby zakończyć:

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("");
 }

Za pomocą tego kodu druga matryca zajęła 259,152 sekundy na ukończenie:

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("");
}

Jaki jest powód dramatycznie różnych czasów działania?


Jak sugerowano w komentarzach, drukowanie tylko System.out.print("#"); trwa 7.8871 sekund, podczas gdy System.out.print("B"); daje still printing....

Jako inni, którzy zauważyli, że działa dla nich normalnie, próbowałem na przykład Ideone.com i obu elementów kod wykonuje się z tą samą prędkością.

Warunki testowe:

  • Uruchomiłem ten test z Netbeans 7.2 , z wyjściem do konsoli
  • Użyłem System.nanoTime() do pomiarów
2598
  1. Spróbuj zmienić rand.nextInt (4) == 0 na i < 250, aby wyeliminować efekt generatora losowego. Możesz skończyć się entropią, która spowalnia losowe generowanie
    2014-02-21 23: 49: 43Z
  2. Obie wydają się działać na tym samym czasie na moim komputerze, ~ 4 sekundy.
    2014-02-21 23: 51: 36Z
  3. jeśli sugerujesz, że drukowanie B zajmuje więcej czasu niż drukowanie # .... dlaczego nie próbujesz drukować wszystkich B & wszystko # zamiast polegać na zmiennej losowej r
    2014-02-21 23: 52: 49Z
  4. Na podstawie zaakceptowanej odpowiedzi najwyraźniej nie próbowałeś jej uruchomić z wyjściem przekierowanym do pliku lub /dev /null.
    2014-02-23 03: 21: 10Z
  5. @ fejese, Random () nie jest kryptograficznym rngiem, więc nie wykorzystuje puli entropii.
    2014-02-25 11: 44: 46Z
2 odpowiedzi                              2                         

Czysta spekulacja polega na tym, że używasz terminala, który próbuje zrobić słowo -opakowanie zamiast zawijania znaków i traktuje B jako znak słowny, ale # jako znak inny niż słowo. Kiedy więc dotrze do końca linii i szuka miejsca na przerwanie linii, widzi natychmiast # i szczęśliwie się tam łamie; mając na uwadze, że w przypadku B musi on kontynuować wyszukiwanie dłużej i może zawierać więcej tekstu do zawinięcia (co może być kosztowne na niektórych terminalach, np. wysyłanie spacji, a następnie wysyłanie spacji w celu zastąpienia zawijanych liter).

Ale to czysta spekulacja.

    
3925
2017-03-13 07: 16: 29Z
  1. To jest właściwie poprawna odpowiedź! Dodanie spacji po B rozwiązuje go.
    2014-02-22 00: 04: 23Z
  2. Jest kilka odpowiedzi, które pochodzą z trudnych doświadczeń. T.J. a ja (odkąd jesteśmy przyjaciółmi) dorastałem w czasach Apple] [i zx80 /​​81. Wtedy nie było wbudowanego zawijania słów. Więc oboje skończyliśmy pisać własne - więcej niż raz. I te lekcje trzymają się ciebie, zostają spalone do twojego jaszczurczego mózgu. Ale jeśli skłaniałeś się do kodowania po tym, gdy twoje słowo otoczy wszystko, lub zrobisz to mco jakiś czas przed uruchomieniem, trudniej jest napotkać problemy z zawijaniem słów.
    2014-02-23 15: 42: 12Z
  3. Genialne dedukcje. Ale powinniśmy uogólniać z tej lekcji i zawsze mierzyć wydajność przy wyeliminowanym wyjściu, kierowanym do /dev /null (NUL w systemie Windows) lub przynajmniej do pliku. Wyświetlanie na dowolnej konsoli jest zazwyczaj bardzo drogie IO i zawsze zakłóca taktowanie - nawet jeśli nie tak dramatycznie myląco jak to.
    2014-02-23 22: 38: 42Z
  4. @ MrLister: System.out.println nie wykonuje pisania słów; to, co wysyłało, to zawijanie słów (i blokowanie, więc System.out.println musiało poczekać).
    2014-02-26 22: 11: 13Z
  5. @ Chris - właściwie argumentuję, że nie wydrukowanie ich JEST rozwiązaniem, a problemem jest uzyskanie dokładnych czasów algorytmu. Za każdym razem, gdy drukujesz na konsolę (dowolnego rodzaju), wywołujesz wszystkie rodzaje przetwarzania zewnętrznego niezwiązane z tym, co testujesz wydajność. To błąd w twojej procedurze pomiarowej, czysty i prosty. Z drugiej strony, jeśli widzisz problem nie jako pomiar, ale zrozumienie rozbieżności, to tak, nie drukowanie to sztuczka debugowania. To sprowadza się do tego, który problem próbujesz rozwiązać?
    2014-03-03 12: 27: 48Z

Przeprowadziłem testy na Eclipse vs Netbeans 8.0.2, oba z Java w wersji 1.8; Użyłem System.nanoTime() do pomiarów.

Zaćmienie:

Mam ten sam czas w obu przypadkach - około 1,564 sekundy .

Netbeans:

  • Używanie „#”: 1,536 sekundy
  • Używanie „B”: 44,164 sekundy

Wygląda na to, że Netbeans ma złą wydajność drukowania na konsoli.

Po dalszych badaniach zdałem sobie sprawę, że problemem jest zawijanie linii maksymalnego bufora Netbeansa (nie ogranicza się do komendy System.out.println), zademonstrowany przez ten kod:

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("");
}

Wyniki czasu są mniejsze niż 1 milisekunda dla każdej iteracji z wyjątkiem każdej piątej iteracji , gdy wynik czasu wynosi około 225 milisekund. Coś w stylu (w nanosekundach):

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

I tak dalej ..

Podsumowanie:

  1. Eclipse działa doskonale z „B”
  2. Netbeans ma problem z zawijaniem linii, który można rozwiązać (ponieważ problem nie występuje w zaćmieniu) (bez dodawania spacji po B („B”)).
183
2015-11-17 21: 34: 55Z
  1. czy możesz rozwinąć swoje strategie badawcze, a następnie co ostatecznie doprowadziło cię do odkrycia, że ​​zawijanie linii było sprawcą? (jestem ciekawy twoich umiejętności detektywistycznych, to znaczy!)
    2016-10-30 04: 49: 45Z
źródło umieszczone tutaj