Debug.WriteLine()   and/or  Console.WriteLine  -  expensive to use many times?

Posted on 2006-04-19
Last Modified: 2012-06-27
Can anyone tell me...

How expensive(processing, or speed) is it to use many Debug.WriteLine()  or Console.WriteLine()  functions throughout your code?   I currently have many, many of these all throughout my app and was wondering how much efficiency i may gain if i comment them all out?

Question by:lblinc
    LVL 12

    Expert Comment

    It does slow down an application. You can easily see the effect by writing a simple console app to count to a million, and do it with and without writing each integer to the console. You could consider caching the output and only writing blocks of 10, 100, 1000 ... lines. Alternatively if you only need them for debugging, surround them with a preprocessor directive such as:

    #if DEBUG

    Alternatively, put the Console.WriteLine call into your own function, and then you can easily turn it on/off to see the effect, or use the application's config file to turn it on/off.

    LVL 12

    Assisted Solution


     If you use Debug class you don't need to modify the code at all, building the application without DEBUG directive will exclude all Debug.WriteLine statements.
     Second, how much a delay of a few seconds does disturb you? Do you really have Writeline statements executed hundreds of thousands times?

      Using Debug and Trace does help a lot, and, as MSDN documentation says:
      "If you use methods in the Debug class to print debugging information and check your logic with assertions, you can make your code more robust without impacting the performance and code size of your shipping product."


    Author Comment

    Any thought on this?  

    It seems that when i use the DEBUG directive..  i.e.   #define DEBUG    and i comment it out like this...

    //#define DEBUG

    it still seems to be still writing out the Debug.WriteLines to the debug window.    Is this correct?

    i thought that when you comment out the #define  that it meant the  #if DEBUG  statement would not be called..   ?
    LVL 12

    Accepted Solution

    The DEBUG symbol is defined in the Debug build configuration properties by default, so commenting out a #define at the top of the file will not necessarily get rid of it if you are doing a DEBUG build. As sumix says, Debug.WriteLine acts in a similar way, though I like to use #if in combination with build configurations that have other symbols defined so that I can debug with/without comments etc. E.g. I have TEST build with the corresponding symbol which I use in conjuction with NUnit to do unit testing, which might require extra console information to be written.

    So your problem is probably that you are building under a debug build configuration in Visual Studio. Try switching between a debug and release configuration and see if there is a difference.

    Just as a note, sumix and lblinc, caching and writing my info lines out 100 at a time made a significant improvement in a piece of code that was building a 15 GB database and was taking 2.3 seconds per transaction over two days with several status messages per transaction. Removing the console writes altogether and meaning I didn't have to maintain a live progress GUI for the production code made even more of a difference. Knocking even fractions of time out of that project was very important. This is maybe a little unusual though ;)


    Featured Post

    Threat Intelligence Starter Resources

    Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

    Join & Write a Comment

    Suggested Solutions

    In order to hide the "ugly" records selectors (triangles) in the rowheaders, here are some suggestions. Microsoft doesn't have a direct method/property to do it. You can only hide the rowheader column. First solution, the easy way The first sol…
    Entity Framework is a powerful tool to help you interact with the DataBase but still doesn't help much when we have a Stored Procedure that returns more than one resultset. The solution takes some of out-of-the-box thinking; read on!
    Sending a Secure fax is easy with eFax Corporate ( First, Just open a new email message.  In the To field, type your recipient's fax number You can even send a secure international fax — just include t…
    This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor ( If you're looking for how to monitor bandwidth using netflow or packet s…

    746 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    15 Experts available now in Live!

    Get 1:1 Help Now