[Python-Dev] bdb.py trace C implementation?

[David Christian]

Hi all,
I've recently written a C version of the trace function used in
figleaf (the coverage tool written by Titus).  After a few rewrites to
add in caching, etc, it gives users a significant speedup.  One person
stated that switching to the C version caused coverage to decrease
from a 442% slowdown to only a 56% slowdown.

You can see my C implementation at:
 
http://github.com/ctb/figleaf/blob/e077155956c288b68704b09889ebcd675ba02240/figleaf/_coverage.c

(Specific comments about the implementation welcome off-list).

I'd like to attempt something similar for bdb.py (only for the trace
function).  A naive C trace function which duplicated the current
python function should speed up bdb significantly.  I would initially
write the smallest part of the C implementation that I could.
Basically the tracing function would call back out to python at any
point where a line requires action.

I'd be willing to maintain the C implementation.  I would be willing
to write those tests that are possible as well.

Is this something that would be likely to be accepted?

Thanks,
David Christian
Senior Software Engineer
rPath, Inc.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] bdb.py trace C implementation?

[David Christian]

On Wed, Apr 1, 2009 at 6:53 PM, Benjamin Peterson  wrote:
> 2009/4/1 Guido van Rossum :
>> Tracing has other uses besides debugging though.
>
> The OP said he wished to implement a C trace function for bdb.
> Wouldn't that make it only applicable to debugging?
>
> Benjamin
>
I was suggesting a speedup for debugging.  However, I could certainly
also contribute my figleaf work that I referenced earlier, with a few
tweaks, as a tracing replacement for the tracing function in trace.py.

My concern with moving the coverage tracing code in particular to the
standard library is that it tries to extract the maximum speed by
being clever*, and certainly has not been out in the wild for long
enough.  I would write something much more conservative as a starting
point for bdb.py.  I expect that any C implementation that was
thinking about performance at all would be much better than the status
quo.

* figleaf checks a regular expression to determine whether or not we
wish to trace a particular file.  If the file is not being traced, I
switch to the profiler instead of the line tracer, which means that
the trace function only gets called twice per function instead of once
per line.  This can give a large speedup when you are skipping the
entire standard library, at some measurable cost per function call,
and a cost in code complexity.

---
David Christian
Senior Software Engineer
rPath, Inc
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com