Message177390
| Author |
xdegaye |
| Recipients |
xdegaye |
| Date |
2012年12月12日.21:37:38 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
When f_trace is NULL, only PyTrace_CALL tracing events trigger the invocation of
the trace function (see trace_trampoline).
maybe_call_line_trace() does quite some work though _PyCode_CheckLineNumber to
find out if the instruction should be traced, and all this work is useless when f_trace
is NULL. The patch checks for f_trace on all tracing events that are not
PyTrace_CALL.
The performance gain with the following test is about 30%. The first test is
with python on the default branch, the second one with the patch applied.
Note: a breakpoint is set at line 1 to ensure that tracing is enabled, without
any breakpoint, pdb sets the trace function to None after a continue.
$ ./python -m pdb /tmp/foo.py
> /tmp/foo.py(1)<module>()
-> import timeit
(Pdb) break 1
Breakpoint 1 at /tmp/foo.py:1
(Pdb) continue
9.226385930000106
The program finished and will be restarted
> /tmp/foo.py(1)<module>()
-> import timeit
(Pdb) q
[62276 refs]
$ ./python -m pdb /tmp/foo.py
> /tmp/foo.py(1)<module>()
-> import timeit
(Pdb) break 1
Breakpoint 1 at /tmp/foo.py:1
(Pdb) continue
7.199809867001022
The program finished and will be restarted
> /tmp/foo.py(1)<module>()
-> import timeit
(Pdb) |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2012年12月12日 21:37:38 | xdegaye | set | recipients:
+ xdegaye |
| 2012年12月12日 21:37:38 | xdegaye | set | messageid: <1355348258.81.0.121484844419.issue16672@psf.upfronthosting.co.za> |
| 2012年12月12日 21:37:38 | xdegaye | link | issue16672 messages |
| 2012年12月12日 21:37:38 | xdegaye | create |
|