print statements and profiling a function slowed performance

[Skip Montanaro]

On Fri, Jun 27, 2014 at 4:35 PM, Ian Kelly <ian.g.kelly at gmail.com> wrote:
> That's got to count for
> something, compared to a raw print that has to wait for the I/O to
> finish.

A raw print basically just tosses some bytes in a stdio buffer (at
least in Unix-land). Stdio does whatever little it does, then passes
the bytes off to the operating system. The underlying OS is then
responsible to see that the bytes get to disk or syslog, or wherever.
It's hard for me to see how that process would be any more time
consuming than the necessary thread switching, followed by what is
essentially the same activity. I haven't looked at the logging module
in awhile (I eventually just rolled my own much simpler version which
only supports what I need), but I don't think it used threads to
perform the actual I/O when it was first written.

Aside... The actual straw that broke the camel's back was that at
work...  One of our C++ programmers wrote a threaded logging module
(to speed up logging by handling it in a thread  - hmmm... sounds
familiar) then wrapped it for use in our Python-based platform. Time
passed, that guy moved on, and I became the sole maintainer of this
particular code base. Finally tired of our applications deadlocking at
inopportune times, I tossed out the threaded stuff and rewrote just
the small bit of the logging module's features I needed in Python. No
performance hit. No deadlocks.

threading-doesn't-always-speed-things-up-ly, y'rs,

Skip