Soru “B” yazdırması neden “#” basılmasından çok daha yavaş?


İki matris oluşturdum 1000 x 1000:

İlk Matrix: O ve #.
İkinci Matris: O ve B.

Aşağıdaki kodu kullanarak, ilk matrisin tamamlanması 8,52 saniye sürdü:

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

Bu kodla, ikinci matrisin tamamlanması 259.152 saniye sürdü:

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

Önemli ölçüde farklı çalışma sürelerinin ardındaki sebep nedir?


Yorumlarda önerildiği gibi, yalnızca yazdırma System.out.print("#"); alır 7.8871 saniye, System.out.print("B"); verir still printing....

Normalde onlar için çalıştığına işaret eden diğerleri gibi Ideone.com Örneğin, her iki kod parçası da aynı hızda çalışır.

Test koşulları:

  • Bu testi Netbeans 7.2, konsoluna çıkışı ile
  • kullandım System.nanoTime() ölçümler için

2417
2018-02-21 23:45


Menşei


Rasgele üretecin etkisini ortadan kaldırmak için rand.nextInt (4) == 0 ila i <250 değiştirmeyi deneyin. Rastgele jenerasyonu yavaşlatan entropiden kaçabilirsiniz. - fejese
Her ikisi de, makinemde aynı miktarda çalışmaktadır, ~ 4 saniye. - Sotirios Delimanolis
B baskısı yazdırmadan daha fazla zaman almanızı önerirseniz # .... neden rasgele değişken r güveniyor yerine tüm B & # # yazdırmaya çalışmayın - Kakarot
Kabul edilen cevaba göre, bir dosyaya veya dev / null'a yönlendirilmiş çıktıyla çalıştırmayı denemediniz. - Barmar
@fejese, Random () bir kriptografik değil ve bu yüzden entropi havuzunu kullanmaz. - Divide


Cevaplar:


Saf spekülasyon yapmaya çalışan bir terminal kullanıyorsunuz Kelime-sarma karakter kaydırma yerine ve davranır B bir kelime karakteri olarak ama # kelime olmayan bir karakter olarak. Yani bir çizginin sonuna ulaştığında ve çizgiyi kırmak için bir yer ararken, bir # hemen hemen ve mutlu bir şekilde orada kırılıyor; oysa BDaha uzun aramaya devam etmek zorundadır ve sarmak için daha fazla metne sahip olabilir (ki bu, bazı uç birimlerde pahalı olabilir, örneğin, geri-alanların çıktısını almak, daha sonra sarılmış harflerin üzerine yazmak için boşluklar bırakmak).

Ama bu saf spekülasyon.


3721
2018-04-03 15:01



Bu aslında doğru cevap! Sonra bir boşluk ekleme B çözer. - Kuba Spatny
Zor öğrenilen deneyimlerden gelen bazı cevaplar vardır. TJ ve ben (arkadaş olduğumuzdan beri) Apple'ın [ve zx80 / ​​81] günlerinde büyüdüm. O zamanlar kelime haznesi yoktu. Yani ikimiz de kendi yazımızı yazdık - bir kereden fazla. Ve bu dersler seninle uğraşırlar, kertenkele beynine yakılırlar. Ancak bundan sonra kod yazdıysanız, ortam kelimeniz her şeyi sararsa veya çalışma zamanından önce manuel olarak yaparsanız, word wrap ile ilgili sorunların üstesinden gelmek daha zordur. - JockM
Parlak kesinti. Fakat bu dersten genellemeliyiz ve her zaman, / dev / null (Windows üzerinde NUL) veya en azından bir dosyaya yönlendirilen çıktı ile performansı ölçmeliyiz. Herhangi bir Konsolda görüntüleme genellikle çok pahalı IO'dur ve her zaman zamanlamaları çarpıtır - bu kadar karmaşık bir şekilde karışık olmasa bile. - Bob Kerns
@MrLister: System.out.println kelime dağıtma yapmaz; Çıktısını veren şey, kelime-kaydırma yapıyordu (ve engellemek, yani System.out.println beklemek zorunda kaldı. - T.J. Crowder
@Chris - aslında, bunları yazdırmamanın, algoritmanın doğru zamanlamalarını alma problemine çözüm olduğunu tartışacağım. Bir Konsola her basışınızda (herhangi bir şekilde), performansınızı test ettiğiniz şeyle ilgili olmayan her türlü harici işlemeye girersiniz. Bu ölçüm prosedürünüzde bir hata, saf ve basit. Öte yandan, sorunu ölçüm olarak değil, tutarsızlığı anladığınızda görüyorsanız, evet, yazdırma hata ayıklama numarasıdır. Aşağı, hangi problemi çözmeye çalışıyorsunuz? - Bob Kerns


Her ikisi de Java sürüm 1.8 ile Eclipse vs Netbeans 8.0.2 üzerinde testler yaptım; kullandım System.nanoTime() ölçümler için.

Eclipse:

Bende var her iki durumda aynı zamanda - etrafında 1.564 saniye.

NetBeans:

  • "#" Kullanarak: 1.536 saniye
  • "B" Kullanımı: 44.164 saniye

Yani, Netbeans'in baskıda konsolda kötü performansı var gibi görünüyor.

Daha fazla araştırma yaptıktan sonra problemin olduğunu anladım. hat-sarma Netbeans maksimum tamponunun (bununla sınırlı değildir System.out.println Bu kod tarafından gösterilen komut):

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

Zaman sonuçları, her yineleme dışında 1 milisaniyeden daha azdır. her beş iterasyon, zaman sonucu 225 milisaniyede olduğunda. Bir şey gibi (nanosaniye cinsinden):

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

Ve bunun gibi..

Özet:

  1. Eclipse "B" ile mükemmel çalışır
  2. Netbeans, çözülebilen bir çizgi sarma sorununa sahiptir (çünkü sorun tutulmadan ortaya çıkmaz) (B'den sonra boşluk eklemeden) ("B")).

148



Araştırma stratejilerinizi detaylandırabilir misiniz? Sonra nihayetinde bu satır-sarmanın suçlu olduğunu öğrenmeye ne dersiniz? (Dedektif yeteneklerini merak ediyorum, bu!) - silph