标签云

微信群

扫码加入我们

WeChat QR Code

为什么是印刷

I generated two matrices of 1000 x 1000:

First Matrix: O and #.
Second Matrix: O and B.

Using the following code, the first matrix took 8.52 seconds to complete:

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

With this code, the second matrix took 259.152 seconds to complete:

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

What is the reason behind the dramatically different run times?


As suggested in the comments, printing only System.out.print("#"); takes 7.8871 seconds, whereas System.out.print("B"); gives still printing....

As others who pointed out that it works for them normally, I tried Ideone.com for instance, and both pieces of code execute at the same speed.

Test Conditions:

  • I ran this test from Netbeans 7.2, with the output into its console
  • I used System.nanoTime() for measurements


Try changing rand.nextInt(4) == 0 to i < 250 to eliminate the effect of the random generator. You might run out of entropy that slows down the random generation

2018年05月27日20分24秒

Both seem to run for same amount of time on my machine, ~4 seconds.

2018年05月27日20分24秒

if you are suggesting that printing B takes more time than printing #....why dont you try to print all B & all # rather than relying on random variable r

2018年05月28日20分24秒

Based on the accepted answer, you apparently didn't try running it with output redirected to a file or /dev/null.

2018年05月27日20分24秒

fejese, Random() is not a cryptographical rng and so doesn't use up the entropy pool.

2018年05月27日20分24秒

This is actually the correct answer! Adding a space after the B solves it.

2018年05月27日20分24秒

There are some answers that come from hard learned experience. T.J. and I (since we are friends) grew up in the days of the Apple ][ and the zx80/81. There was no built in word wrap back then. So we both ended up writing our own — more than once. And those lessons stick with you, they get burned in to your lizard brain. But if you leaned to code after that, when your environment word wraps everything, or you do it manually prior to runtime, it is harder to run into the issues with word wrap.

2018年05月27日20分24秒

Brilliant deduction. But we should generalize from this lesson, and always measure performance with output either eliminated, directed to /dev/null (NUL on Windows) or at least to a file. Displaying on any sort of Console is generally very expensive IO, and always distorts timings -- even if not as dramatically confusingly as this.

2018年05月27日20分24秒

MrLister: System.out.println doesn't do wordwrapping; the thing it was outputting to was doing word-wrapping (and blocking, so System.out.println had to wait).

2018年05月27日20分24秒

Chris -- actually, I'll argue that not printing them IS the solution, to the problem of getting accurate timings of the algorithm. Each time you print to a Console (of any sort), you're invoking all manner of external processing not related to what you're testing the performance of. That's a bug in your measurement procedure, pure and simple. On the other hand, if you view the problem not as measurement, but understanding the discrepancy, then yes, not printing is a debugging trick. It comes down to, which problem are you trying to solve?

2018年05月27日20分24秒

can you elaborate on your research strategies and then what finally led you to find out that line-wrapping was the culprit? (i'm curious about your detective skills, that is!)

2018年05月27日20分24秒