"Benjamin Niemann" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > km wrote: > >> Hi all, >> >>> thing. If *all* your loops are going to do is print stuff, then you're >>> doing the right thing with the version that "emits values". >> >> ya most of the loops print values. > > In that case, you are interested in IO performance. The time spent > handling > the loop is not significant compared to the time spent executing the > 'print' statement - which is a very complex operation despite its simple > usage. > > An implementation where a simple control flow structure has an measurable > impact on the overall timing of an IO bound program would really > suprising. > Python suprises me often, but in different ways ;) > > Perhaps you could try to use sys.stdout.write() directly, avoiding the > overhead of 'print'. Perhaps there are differences between the (default) > output buffering settings of perl and python.
According to postings some years ago, the perl folks have worked specially hard to speed I/O, even to the point of replacing or rewriting some of the C stdio library, at least for some systems. Hence, at that time, Perl was expected and known to be noticeably faster than Python on such systems. Since then, Python I/O has been sped up to at least make better use of stdio, so the gap may be less. This suggests to me: 1. One should not generalize to other aspects of computation. If, for instance, Python got Numerical Python before Perl got the equivalent, then it would have been multiples faster at numerical computation. 2. One should compare the lastest with the lastest to compare the results of catch up with stay ahead efforts. 3. One should test computations that are relevant to the question being asked. Python I/O speedups were aimed at 'for line in somefile: ...' and equivalent outputs, not in quickly writing thousands or millions of characters one at a time. Terry J. Reedy -- http://mail.python.org/mailman/listinfo/python-list
