Does 'unused' Debugging Serial commands slow down my process

I usually have a lot of things being sent to my terminal via Serial.print() for debugging. Once my project is complete and I no longer have it connected a laptop, do these commands still send out the data? Will this eat up time on the Atmega328, making it more likely to miss something else, like incoming serial from an RFID tag on a software serial port, or I2C data, etc?

Will this eat up time on the Atmega328

Shifting the data out a wire or into a pile on the floor takes the same amount of time. However, that time happens in interrupts, so it is not likely to have a major impact.

If it was going to cause a problem it would do so while you had your Arduino connected to the PC.

However it would probably be a good general practice to remove or comment-out debug code when a particular function works properly.

...R

SouthernAtHeart:
I usually have a lot of things being sent to my terminal via Serial.print() for debugging. Once my project is complete and I no longer have it connected a laptop, do these commands still send out the data? Will this eat up time on the Atmega328, making it more likely to miss something else, like incoming serial from an RFID tag on a software serial port, or I2C data, etc?

If you use preprocessor directive (#define DEBUG ) you can stop the compiler from including your final code.
Than you do not have to worry about slowing down the application and save few bytes of memory same time.

Removing the directive or using #undef works gooder than deleting / commenting out your debug code.
And it is faster if you have to go back to debugging.
Not that you ever need to do that , right?

#define DEBUG
//#undef DEBUG

#ifdef DEBUG
Serial.print(...
....
#endif

Vaclav:
If you use preprocessor directive (#define DEBUG ) you can stop the compiler from including your final code.
Than you do not have to worry about slowing down the application and save few bytes of memory same time.

Removing the directive or using #undef works gooder than deleting / commenting out your debug code.
And it is faster if you have to go back to debugging.
Not that you ever need to do that , right?

#define DEBUG
//#undef DEBUG

#ifdef DEBUG
Serial.print(...
....
#endif

It may be more useful to define DEBUG to a non-zero value so it can be used with #if rather than #ifdef:

#define DEBUG 1

#if DEBUG
// ...
#endif

If DEBUG is 0 or not defined, the block inside #if...#endif will not be compiled.

If DEBUG is defined as 0 or non-zero, you can even use it in run-time expressions:

if (DEBUG) {
    // ...
}

Since the value is known at compile time, the compiler will remove all code inside the "if" statement if DEBUG is 0.

Yes, the Arduino still sends out the serial and takes up some time but if it does nog mess up in debug it will not mess it up later.

But I'm with Vaclav of the #define DEBUG and #ifdef part. Just comment #define DEBUG to stop debug mode. A comment is clear to have no impact on the code and so does the rest.

SouthernAtHeart:
like incoming serial from an RFID tag on a software serial port

Why on earth use soft serial for the RFID when you have the hardware serial unconnected... I would use the soft serial for debug and the hardware for the real purpose of the project.

septillion:
Why on earth use soft serial for the RFID when you have the hardware serial unconnected... I would use the soft serial for debug and the hardware for the real purpose of the project.

Glad you brought that up:
I often do this, only for the reason of using the hardware for debugging all during the making of the project. In the end, most projects never have a laptop/serial monitor left. I even design my boards with a solder jumper from the incoming port to be connected to a digital pin, or the RX pin. after I'm done designing/making/programming/debugging, I usually just leave the scenario with the software serial, if it's working okay. Then if I ever need to go back to a project and tweek it or check on status's I may have saved to the EEPROM, I still have the hardware Serial.
I guess if I were to upgrade beyond the UNO/Atmega328P or Atmega328AU, I'd have USB connectivity AND hardware serial. But I'm so familiar with the Atmega328 chip, and thinking too old to learn a new one... It would be great to have built in USB and do away with needing a FTDI header cable, especially when giving a project to others that don't have the FTDI cable.

With the ATmega328AU chip, all I need is a couple decoupling caps, a crystal and 2 crystal caps, and a resistor and cap for the reset pin. From there I'm good to add in what ever I'm designing. If I were to attempt the Leonardo's chip, I guess it would be too different? I'll take a look at it and see how much more complicated it is. I don't think I could SMD solder anything smaller than the Atmega328AU, though.

But in my opinion it would make more sens to use the hardware serial for the piece of hardware you connect to in your project and use soft serial for some debug info. Or use both for debug if the debug messages don't confuse whatever serial device you use. That's because I think the hardware serial is more reliable, don't hold up the program etc. Most of the time it's not that bad to miss a debug message once or get it somewhat delayed..

...but the laptop is only connected to the hardware serial pin on an UNO.