Do Serial.println commands or //comments slow down a program?

Generally speaking, how much does the use of Serial.print and Serial.println messages slow down a program? What about a lot of //code comments?

I realize there's some overhead with every line of code, but is it worth stripping out all of my helpful debug statements and comments? I would prefer to leave the statements in place, but don't know if their presence could be impairing my robot's responsiveness.

Project: Using a Mega 2650 and an Uno to build two line following robots. I use a lot of Serial.println messages for monitoring (via serial cable) what the program is doing and have a lot of comments in the code.

TIA for any feedback! -potus98

Generally speaking, how much does the use of Serial.print and Serial.println messages slow down a program?

Depends on the amount of data being sent, the frequency of the sends, the baud rate, and the version of the IDE being used.

With 1.0+, serial data is buffered for sending, so as long as you never fill the buffer, or use flush(), sending serial data has minimal impact.

What about a lot of //code comments?

Stripped out by the compiler, so none, zip, zilch, nada.

potus98: Generally speaking, how much does the use of Serial.print and Serial.println messages slow down a program?

You will have to provide details.

What about a lot of //code comments?

Comments are free.

I realize there's some overhead with every line of code, but is it worth stripping out all of my helpful debug statements

Is your program having performance problems? Have you worked out all the bugs or is the program still a work-in-progress?

and comments?

No.

I would prefer to leave the statements in place, but don't know if their presence could be impairing my robot's responsiveness.

Highly doubtful. A motor is orders of magnitude slower to respond than an AVR processor. Your Arduino could command a motor and have time left over to take its mother out to lunch.

and have time left over to take its mother out to lunch.

Unless it orders drinks. Then, all bets are off.

And have you removed every single call to "delay"?

Depends on the amount of data being sent, the frequency of the sends, the baud rate, and the version of the IDE being used.

Serial.print("Usually, not more than some text and a few: "); Serial.println(variables);

I guess the frequency is pretty high since a message is sent at just about every if statement, function call, or other key point. Glancing through the code, it looks like about one Serial.print/ln message for every 4-5 lines of real code.

9600 baud, Arduino IDE 1.0.1

Doubt a buffer has ever been filled, but I don't know for sure. Have never received buffer overflow errors or dropped characters. Have never used flush().

Doubt a buffer has ever been filled, but I don't know for sure.

It's only a 64 byte buffer.

Have never received buffer overflow errors or dropped characters.

You wouldn't, because when the buffer gets full, Serial.write() (and all the print() overloads that call it) blocks until there is room in the buffer.

9600 baud

Why? You can bump that to 115200, and cut your serial data transfer time by a factor of 12.

PaulS: Why? You can bump that to 115200, and cut your serial data transfer time by a factor of 12.

250000 is an even better choice.

You don’t have to remove print statements if you enclose them in a #define that you can enable when you want prints and disable when you don’t.

250000 is an even better choice.

Though not supported by the Serial Monitor, is it?

PaulS: 250000 is an even better choice. ... Though not supported by the Serial Monitor, is it?

Sadly, no.

I wonder if @eried could be convinced to add it.

Like... arduino uart supports 250k baud and the powers-that-be still keep it secret ?!? I'd better take notice before this whole thread is removed ]:D

Thank you all for helpful information. In summary:

Generally speaking, how much does the use of Serial.print and Serial.println messages slow down a program?

  • For most applications, impact of serial printing is likely to be negligible for short debugging type messages. The value of having the information far outweighs any performance concerns.
  • Any delay() statements will have far more impact than a series of print and println statements.
  • Frequent printing of a lot of text (pages of text?) might be of interest, but the impact of Serial printing can be further reduced by increasing the communication baud rate from 9600 to 115200.

What about a lot of //code comments?

  • No performance impact. Comments are stripped out by the compiler at compile time.

is it worth stripping out all of my helpful debug statements and comments? I would prefer to leave the statements in place, but don't know if their presence could be impairing my robot's responsiveness.

marco_c commented:

You don't have to remove print statements if you enclose them in a #define that you can enable when you want prints and disable when you don't.

I'm uncertain if this is what marco_c meant, but I tested the following construct within in my code and it seems to work fine.

// Toggle the pairs of lines below to enable/disable global serial printing
// assumes all Serial.print and Serial.println statements have been replaced with
// debugprint or debugprintln
//
// Enable debug printing...
//#define debugprint Serial.print
//#define debugprintln Serial.println
// ...OR disable debug printing
#define debugprint //
#define debugprintln //

...farther down in your code...

debugprint ("Here is a debug message showing variableFoo is currently: ");
debugprintln (variableFoo);

Note the space between debugprint and the open parenthesis. debugprint("stuff"); is not recognized by the #define functionality as something to replace. However, debugprint ("stuff"); IS recognized and replace with Serial.print or //.

That's not a good way to go about conditional debug compilation. Better is something like

#ifdef DEBUG_FLAG
#define DEBUG(x)  Serial.print (x)
#else
#define DEBUG(x)
#endif

(Purists like me will say even that's not ideal, but it is better)