0

When starting a "Runnable jar" it doesn't by default start a console. If you would like to invoke a terminal you can run in command prompt (for windows users) "java -jar nameofyourprogram.jar" and you will be able to see the Console.

My question is when you use System.out.println() if your console is not displayed and you print information to a console, does it still get printed? does it slow down your program at all (for lots of print statements)

Naturally with a GUI you wont have a console loaded unless you run the command I put above, so if you are having a lot of print statements, does it still affect the speed of your program, and are they still printed? (even thought no terminal/console is displayed)

Loligans
  • 497
  • 9
  • 24

2 Answers2

1
does it slow down your program at all (for lots of print statements)

yes you can manually test by using System.nanoTime();

Note I have seen people use System.currentTimeMillis() to check the execution time but this is not the right way . Use System.nanoTime(); to check execution time.

System.currentTimeMillis() is implemented using the GetSystemTimeAsFileTime method, which essentially just reads the low resolution time-of-day value that Windows maintains. Reading this global variable is naturally very quick - around 6 cycles according to reported information. This time-of-day value is updated at a constant rate regardless of how the timer interrupt has been programmed - depending on the platform this will either be 10ms or 15ms (this value seems tied to the default interrupt period).

System.nanoTime() is implemented using the QueryPerformanceCounter / QueryPerformanceFrequency API (if available, else it returns currentTimeMillis*10^6). QueryPerformanceCounter(QPC) is implemented in different ways depending on the hardware it's running on. Typically it will use either the programmable-interval-timer (PIT), or the ACPI power management timer (PMT), or the CPU-level timestamp-counter (TSC). Accessing the PIT/PMT requires execution of slow I/O port instructions and as a result the execution time for QPC is in the order of microseconds. In contrast reading the TSC is on the order of 100 clock cycles (to read the TSC from the chip and convert it to a time value based on the operating frequency). You can tell if your system uses the ACPI PMT by checking if QueryPerformanceFrequency returns the signature value of 3,579,545 (ie 3.57MHz). If you see a value around 1.19Mhz then your system is using the old 8245 PIT chip. Otherwise you should see a value approximately that of your CPU frequency (modulo any speed throttling or power-management that might be in effect.)

SpringLearner
  • 13,738
  • 20
  • 78
  • 116
1

Naturally with a GUI you wont have a console loaded unless you run the command I put above, so if you are having a lot of print statements, does it still affect the speed of your program, and are they still printed?

The best answer for any performance question is to test it. Here's a quick sample program:

import java.io.*;

class Test {

    public static void main(String[] args) throws Exception {
        // Untimed, for the sake of JIT compilation
        for (int i = 0; i < 100000; i++) {
            System.out.println("Foo");
        }
        // Now let's time it.
        long start = System.nanoTime();
        for (int i = 0; i < 100000; i++) {
            System.out.println("Foo");
        }
        long end = System.nanoTime();
        String outputPath = "c:\\users\\jon\\test\\results.txt";
        try (FileWriter writer = new FileWriter(outputPath)) {
            writer.write((end - start) + " nanoseconds");
        }
    }
}

Running this from a console, but hiding it, on my laptop I get a result of 5604097078 nanoseconds.

Running it from Windows explorer, so there's no output, I get a result of 3339245234 nanoseconds. (Obviously I've run it a few times - those are just typical results.) So while it's significantly more efficient to write to a console which isn't actually doing anything, it's far from free. Whether it's a problem in your application is a different matter.

And no, the output really isn't written anywhere, as far as I'm aware. If you're using this for logging, you'd be better off using a dedicated logging package, which will allow you to disable it for much more efficient no-op logging, and also allow you to log to a specific file or wherever you want.

Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • As far as I can imagine, then you're still writing to stdout, however noone (eg the console), is spending time reading it. – Skeen Oct 05 '13 at 07:56
  • One could try running the program, and redirecting stdout to a file, this should yield somewhat the GUI execution time, I guess. – Skeen Oct 05 '13 at 07:57
  • I would actually be rather shocked if the output wasn't pushed onto the stdout, just because your running in GUI mode, because this is clearly a semantic change in the program, say if I redirect the stdout to my stdin, the running in GUI mode, assuming this disables the print statements, will have changed my program input. – Skeen Oct 05 '13 at 08:00
  • Also I agree on using some logging package, which allows one to disable logging, the check of 'if(is_logging_enabled)', will by time by the JIT be removed, as the JIT detects that it is always the case, at the same time, the JIT may start watching writings to is_logging_enabled, to ensure the invariant it assumed isn't broken. – Skeen Oct 05 '13 at 08:06