 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / November 2005System.out calls
Do frequent System.out calls hamper performance? Bruce Lee : > Do frequent System.out calls hamper performance? Yes, even a single one does. You should avoid the use of System.out at all cost. Jokes aside, what kind of application are you talking about? On Thu, 03 Nov 2005 05:24:20 GMT, "Bruce Lee" <blah@blahbllbllahblah.com> wrote, quoted or indirectly quoted someone who said : >Do frequent System.out calls hamper performance? It is better to block up a string then output it all at once.  SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. > Do frequent System.out calls hamper performance? Well, System.out is synchronized, so yes, frequent calls will cause some bottlenecking. If you really overuse it, it's easy to destroy any benefits you gain from multithreading. And output in general is _slow_ compared to memory operations. As Roedy (rightly) advises, it's best to store up output for a single System.out call. One common way is to have a buffered writer with manual flush, backed by System.out and only flushed every so often. SignatureRoss Bamford - rosco@roscopeco.remove.co.uk > [...] And output in general is _slow_ compared to > memory operations. And output to a TTY (in Unix) or to a Windows "console" can be /very/ slow even compared to I/O in general. -- chris Chris Uppal coughed up: >> [...] And output in general is _slow_ compared to >> memory operations. [quoted text clipped - 3 lines] > > -- chris Coding from your 110 baud teletype again? ;) Signature"His name was Robert Paulson. His name was Robert Paulson. His name was Robert Paulson..." Ross Bamford coughed up: >> Do frequent System.out calls hamper performance? > > Well, System.out is synchronized, so yes, frequent calls will cause > some bottlenecking. *ONLY* if there are different threads attempting the system.out.{whatever}at the same time! It is a slow beast anyway, simply because it is i/o, but you may be misleading the newbie a little. A synchronized method doesn't block anything other than what it is synchronizing on, in this case all the java.io.PrintStream methods synchronize on their own instances. > If you really overuse it, it's easy to destroy > any benefits you gain from multithreading. And output in general is [quoted text clipped - 3 lines] > System.out call. One common way is to have a buffered writer with > manual flush, backed by System.out and only flushed every so often. > Ross Bamford coughed up: >> [quoted text clipped - 11 lines] > anything other than what it is synchronizing on, in this case all the > java.io.PrintStream methods synchronize on their own instances. True, I should have been clearer that this applies specifically to multithreaded programs, where System.out is called from different threads. The time taken to actually obtain a (previously open, obviously) synchronization lock is vanishingly small, so it's not an _automatic_ performance hit (that comes from the IO ;)) Apologies for the confusion. SignatureRoss Bamford - rosco@roscopeco.remove.co.uk cheers Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2009 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.