<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7233.28">
<TITLE>RE: [Python-Dev] Unifying trace and profile</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>I, Robert, wrote:<BR>
> 1. Allow trace hooks to receive c_call, c_return,<BR>
> and c_exception events (like profile does).<BR>
<BR>
and Nicholas Bastin replied:<BR>
> I can easily make this modification. You can also<BR>
> register the same bound method for trace and profile,<BR>
> which sort of eliminates this problem.<BR>
<BR>
Wonderful! It looked easy. :)<BR>
<BR>
I worked around this by registering one function for trace, and another for profile. The profile function rejects any non-C event and then calls the trace function.<BR>
<BR>
Robert:<BR>
> 3. Expose new sys.gettrace() and getprofile() methods,<BR>
> so trace and profile functions that want to play nice<BR>
> can call sys.settrace/setprofile(None) only if they<BR>
> are the current hook.<BR>
<BR>
Nicholas:<BR>
> Not a bad idea, although are you really running into<BR>
> this problem a lot?<BR>
<BR>
Well, not "a lot", as I don't expect I'll write very many debuggers in my lifetime ;) But it's important when you have multiple, different debugging systems running at once, either to take advantage of the strengths of each, or to debug a debugger.<BR>
<BR>
Bob:<BR>
> 4. Make "the same move" that sys.exitfunc -> atexit made<BR>
> (from a single function to multiple functions via<BR>
> registration), so multiple tracers/profilers can play<BR>
> nice together.<BR>
<BR>
Nick:<BR>
> It seems very unlikely that you'll want to have a trace<BR>
> hook and profile hook installed at the same time, given<BR>
> the extreme unreliability this will introduce into the<BR>
> profiler.<BR>
<BR>
True; this request is partly driven by the differing capabilities of each (only profile can handle C events at the moment). Being able to compose debuggers as described above is another reason. Anything else is just the usual (often ignorable) desire for elegance.<BR>
<BR>
Bob:<BR>
> 5. Allow the core to filter on the "event" arg before<BR>
> hook(frame, event, arg) is called.<BR>
<BR>
Nick:<BR>
> What do you mean by this, exactly? How would you use<BR>
> this feature?<BR>
<BR>
As you hinted, I mean that call_trace would only call the trace function if the current event were in a list of "events I want to monitor"; that list of events could be supplied, for example, with a new sys.settrace(func[, events]) signature, with "events" deafulting to all events for backward compatibility. A single int could be used internally, where each bit represents one of the event types.<BR>
<BR>
This would be necessary if trace and profile were unified (see next). If they're not, it's less compelling.<BR>
<BR>
Bob:<BR>
> 6. Unify tracing and profiling, which would remove a<BR>
> lot of redundant code in ceval and sysmodule and free<BR>
> up some space in the PyThreadState struct to boot.<BR>
<BR>
Nick:<BR>
> The more events you throw in profiling makes it slow,<BR>
> however. Line events, while a nice thing to have,<BR>
> theoretically, would probably make a profiler useless.<BR>
<BR>
Sure. If trace functions can receive C events, then there's no need to add that to profiling. I guess I just see profiling as a "stripped down" version of the general trace architecture, and wonder if it couldn't be that in reality as well as appearance; that is,<BR>
profiling becomes tracing with the 'line' events ignored (before they reach back into your Python trace function and slow everything down). But I also note that the current hotshot uses PyEval_SetTrace "if (self->lineevents)", and PyEval_SetProfile otherwise.<BR>
<BR>
Bob:<BR>
> 7. As if the above isn't enough of a dream, it would be nice<BR>
> to have a bytecode tracer, which didn't bother with the<BR>
> f_lineno logic in maybe_call_line_trace, but just called<BR>
> the hook on every instruction.<BR>
<BR>
Nick:<BR>
> I'm working on one, but given how much time I've had to<BR>
> work on my profiler in the last year, I'm not even going<BR>
> to guess when I'll get a real shot at looking at that.<BR>
><BR>
> My long-term goal is to eliminate profiling and tracing<BR>
> from the core interpreter entirely and implement the<BR>
> functionality in such a way that they don't cost you<BR>
> when not in use (i.e., implement profilers and debuggers<BR>
> which poke into the process from the outside, rather<BR>
> than be supported natively through events). This isn't<BR>
> impossible, but it's difficult because of the large<BR>
> variety of platforms. I have access to most of them,<BR>
> but again, my time is hugely constrained right now for<BR>
> python development work.<BR>
<BR>
Ah. Sorry to hear that. :/ But no worries on my end; if only #1 can be done someday, I'll be extremely happy. Find me at PyCon, I'll buy you a drink. :)<BR>
<BR>
<BR>
Robert Brewer<BR>
System Architect<BR>
Amor Ministries<BR>
fumanchu@amor.org</FONT>
</P>
</BODY>
</HTML>