code coverage tool

[John Roth]

"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
server.
> > > > 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
and
> 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
assume
> > 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
hooks
> from parent threads. Basically what happens is you get
profile/coverage
> 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
it
> 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
profiler
> (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
more,
for a threaded approach. For a coverage analyzer, that's not a
significant
problem for me. If you're trying to do volume testing, it could be
prohibitive.

John Roth

>
> -Dave
>