From: Peter Hansen [mailto:peter at engcorp.com]

Hmmm... I didn't see any implication that speed was even remotely
a concern for the OP. After all, he did ask to *print* each line
as it executed. What could possibly be slower than that?
(I doubt he would care to deal with the volume of information
generated when using this with a large program anyway... needs
a way to turn it on and off, at least.)
Very true - hence my qualification. The speed comes into effect when tracing
a long-running process - for example, while using the "standard" two
coverage tools (trace.py and coverage.py) performance was unacceptably slow
for coverage of some unit tests here (well, once I'd hacked them to actually
allow unittest to determine what was a test case ...).
My standard comments about Python speed and Knuth's comments about
premature optimization apply...
Oh yeah. Unfortunately, tracing becomes a real bottleneck if done wrongly -
I've achieved two orders of magnitude improvement since I first started on
this tool - both in performance and memory use.
I'm looking forward to seeing your tool though, Timothy. :)
I'd love it to eventually become part of the core - I *expect* I'll be able
to release it (but of course, it's up to my employer ...). It's doing
everything I want now except for determining exactly which zero-count lines
can be safely ignored (comments, multiline expressions). Oh - and I haven't
got an actual "trace as you go" mode (which is the topic of this thread ;)
but that will be easy to add. And I haven't got any path coverage analysis
yet - the data is captured, but no analysis is performed. And it currently
does a relatively primitive text-only coverage dump. And ...


Tim Delaney

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 18 | next ›
Discussion Overview
grouppython-list @
postedSep 19, '02 at 2:54a
activeSep 22, '02 at 11:51p



site design / logo © 2022 Grokbase