On Dec 5, 7:36 am, Roy Smith <r...@panix.com> wrote: > In article <29c74a30-f017-44b5-8a3d-a3c0d6592...@googlegroups.com>, > > > > > > > > > > SherjilOzair <sherjiloz...@gmail.com> wrote: > > Hello list, > > > When it comes to printing things while some computation is being done, there > > are 2 extremes. > > > 1. printing speed is slower than data-to-print generation speed. In this > > case, printing is a bottleneck. Examples: "for i in xrange(2**30): print i". > > Without the print, this code would be much faster. > > > 2. data-to-print generation speed is slower than printing speed. So, this > > case, printing does now slow you down much. Example: for m in matrices: > > print > > m.inverse() # inverse is a time-taking function > > > These two cases are pretty easy. But, my question is, how to draw the line? > > How do I know that print is slowing me down, and I should probably remove > > some of them? Is there a scientific way to do this, rather than just > > intuition and guesswork? > > > I can clarify, if needed. > > Thanks, > > Sherjil Ozair > > The profiler (http://docs.python.org/2/library/profile.html) is your > friend.
One added caveat: When 'printing' is the bottleneck it can be - in the actual disk/console/network I/O - in the str/repr builtin/customized that precedes it [Or both of course] So after you identify printing as the bottleneck, it may be worthwhile to print to a dummy device. On Unix one usually uses /dev/null for this but whether that will help clarify or muddy the picture I am not sure (Whats the overhead to writing to null?) A more internal-to-python method may be to replace the print with a str/repr assigned to say a global variable -- http://mail.python.org/mailman/listinfo/python-list