11

I have an application that has 4 threads. Each thread is actually a Timer and does a seperate job in specific intervals. These threads show their logs by using Console.Writeline. The performance is very important in this application. I wanted to know whether removing of Console.Writeline will tune the performance of this application or not?

Pooya Yazdani
  • 1,141
  • 3
  • 15
  • 25
  • 5
    Every code that is not executed will improve performance. Whether it is significant is another question - and impossible to answer without more details. Like in which interval your timers fire, what other work they actually do (that might totally dwarf the `Console.WriteLine` statements), and how much they are already synchronized (implicitly) by other code. – Christian.K Aug 27 '13 at 12:05
  • Actually it's for monitoring not debugging – Pooya Yazdani Aug 27 '13 at 12:05
  • Why do you have to ask this if you could just try it, it's not that hard... For production environment (considering importance of performance), you should keep just most essential debug messages. – Marko Gresak Aug 27 '13 at 12:06
  • 3
    Seeing how the console is a shared resource between the four threads, whenever one thread is writing to it the others will have to wait until it's done. (That's in addition to the impact of the IO in the first place.) That said this heavily depends on how often you're logging the error messages in proportion to the time spent doing useful. – millimoose Aug 27 '13 at 12:07
  • 2
    Anecdotaly speaking I've seen log4net statements show up in profiler logs as being somewhat significant. I can see Console.Writeline being similar. Specifically the use of `string.Format(....)` if put inside the Writeline statement could start to be significant. – chollida Aug 27 '13 at 12:08
  • Dear millimoose I know that I can try it, but I'd be glad to know others experiences and comments. – Pooya Yazdani Aug 27 '13 at 12:15
  • 2
    @Pooya None of which will apply to your situation, seeing as **it depends**. Like, if you're logging a lot of stuff, and can't log less stuff, it would actually be a terrible idea to try a solution suggested by someone who logs less crap but needs throughput over logging accuracy. There's also a difference if you're logging static output or if you're using `string.Format()` heavily, as the load shifts between the CPU and IO. – millimoose Aug 27 '13 at 12:17
  • It's obvious that any statement will take some CPU time... I guess this will help you: [Click here](http://stackoverflow.com/questions/5272177/console-writeline-slow) – g-newa Aug 27 '13 at 12:13
  • I think you should consider using Debug or Trace. See https://stackoverflow.com/a/47126324/4821032 – Xan-Kun Clark-Davis Nov 05 '17 at 20:36

3 Answers3

10

Yes, executing Console.WriteLine takes a measureable amount of time.

Removing the Console.WriteLine call or changing it to a buffered background thread writing the data would really speed up the application.

However your milage might vary depending on the OS in use.

CodingBarfield
  • 3,392
  • 2
  • 27
  • 54
  • The only problem with queuing it on a background thread is that the logging isn't accurate anymore and the threads could already been finished, and still the logging is written to the console. – Jeroen van Langen Aug 27 '13 at 12:07
  • @JeroenvanLangen It's hardly the only problem. You have to consider what priority the logging thread would have. If it's higher than the worker threads, it wouldn't help at all. If it's lower than the worker threads, either the buffer could grow out of bounds and your application would run out of memory, or the threads could end up waiting on a fixed-capacity buffer. Essentially, for this to work at all you must know for certain that the application has enough "downtime" to write out the buffered logging output. – millimoose Aug 27 '13 at 12:10
9

There may be two issues with Console.WriteLine in regards to performance:

  1. IO is not typically a "fast" operation.

  2. Calls to WriteLine are synchronized, i.e. if two threads want to write, one of them blocks on the WriteLine waiting for the other to finish writing. From MSDN on console:

I/O operations that use these streams are synchronized, which means that multiple threads can read from, or write to, the streams.

That said, the only way to understand if the time spent on Console.WriteLine has an impact on the performance of your specific application is profiling it. Otherwise it's premature optimization.

Paolo Falabella
  • 24,914
  • 3
  • 72
  • 86
6

If it's for debugging purpose, you should rather use: Debug.WriteLine(..), because these are not included in the release version.

Jeroen van Langen
  • 21,446
  • 3
  • 42
  • 57
  • 2
    I don't see how this answers the OP's question. You might want to gather logging output from the release version of an app as well, and anyway it's beside the point what the purpose of the logging is. – millimoose Aug 27 '13 at 12:05
  • 1
    You can use Trace.WriteLine, see http://stackoverflow.com/questions/179868/trace-vs-debug-in-net-bcl – Jakub Pawlinski Apr 20 '15 at 10:18