code coverage tool
johnroth at ameritech.net
Tue Mar 4 03:09:14 CET 2003
"Dave Brueck" <dave at pythonapocrypha.com> wrote in message
news:mailman.1046726706.1292.python-list at python.org...
> On Mon, 3 Mar 2003, John Roth wrote:
> > "Dave Brueck" <dave at pythonapocrypha.com> wrote in message
> > > > The first few messages seem not to have made it to my news
> > > > Look on the Vaults for PyCover. It mostly does what you
> > > > want, and if it doesn't, it's easy enough to change.
> > >
> > > No automatic support for multithreaded programs though, right?
> > I'm not sure what you mean by support for multi-threaded programs.
> Ever tried tracing/profiling a multithreaded program in Python? Try it
> you'll know what I mean. ;-) (see below)
> > Python's threading model is to have the interpreter switch back
> > and forth between its "threads" using a byte code count, so I'd
> > that all you would need to do would be to put a monitor or something
> > equivalent in the trace exits.
> It's not that simple - new threads don't inherit the trace/profile
> from parent threads. Basically what happens is you get
> data for the parent thread and that's it - not very useful.
> One approach is to introduce a "shim" in threading and hook into
> sys.settrace yourself (so that you don't have to manually set the new
> trace/profile function each time you create a thread) but when I tried
> the resulting program was too darn slow - a pure Python profiler per
> thread was too much I guess (maybe for code coverage it wouldn't be so
> bad). Last time I tried using the same approach with the hotshot
> (the one written partially in C) Python crashed a lot. Oh well. :)
My experiance with pyCover is that it is about a factor of three slower
than running without it, so I'd expect the same slowdown, or somewhat
for a threaded approach. For a coverage analyzer, that's not a
problem for me. If you're trying to do volume testing, it could be
More information about the Python-list