Java Development

[bo]

I couldn't find any other posts about this, but I've always wondered about this.  Obviously if you have the debugging window open and are printing a lot of info, it definitely slows it down because of the scrolling in the IDE.  However, does it affect the application once it's on the device and isn't being debugged via USB?

Do you guys remove your println's when you package your code for release?

Message Edited by bo on 04-28-2009 03:10 PM

[RexDoug · Accepted solution]

In my experience, this output does not slow down the program significantly when running on the device. I believe that the OS eats the output if there is no USB debug connection.

Having said that, we remove "most" of these lines for a production build.

[webmasterpdx]

I personally would create a function called debug or something and redefine it for your production build.

Thats the easiest way to deal with it.

Actually, in the past I've generally had 2 levels. One for my personal debug and another for real time debug (finding failures) and these outputs coudl eb sent to the event log so that if my app fails, I can have the customer send me his event log to give me a clue as to whats wrong....

To answer your question, println does slow things down a little and especially if placed in certain critical areas. Slow is a relative thing. If asking compareed with the time it takes to press a button, then no, but if compared with the time to draw a line then yes....:-)

I hope that helps.

-Donald

[bo]

I appreciate the replies.

webmasterpdx: I actually do the exact same thing with 2 levels of logging for eventlog + system.out.println.

The other thing to keep in mind is security because someone could just plug their device into their computer and see all your output.

[baskaraninfo]

I think you should not print the sensitive data using System.out.println method. Eventhough using, you should comment it before going production.

Message Edited by baskaraninfo on 04-29-2009 12:12 AM

[webmasterpdx]

You can overcome security issues by outputting information codes instead where you want something kept secure.

You can also enable/disable the output of the lowest level of messages that you only use in-house through the use of a flag. Then the messages can be used as a regression test on that class.