svn+ssh://pythondev@svn.python.org/python/trunk
........
r72912 | benjamin.peterson | 2009-05-25 08:13:44 -0500 (Mon, 25 May 2009) | 5 lines
add a SETUP_WITH opcode
It speeds up the with statement and correctly looks up the special
methods involved.
........
r72920 | benjamin.peterson | 2009-05-25 15:12:57 -0500 (Mon, 25 May 2009) | 1 line
take into account the fact that SETUP_WITH pushes a finally block
........
r72940 | benjamin.peterson | 2009-05-26 07:49:59 -0500 (Tue, 26 May 2009) | 1 line
teach the peepholer about SETUP_WITH
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r73064 | antoine.pitrou | 2009-05-30 23:27:00 +0200 (sam., 30 mai 2009) | 4 lines
Issue #5330: C functions called with keyword arguments were not reported by
the various profiling modules (profile, cProfile). Patch by Hagen Fürstenau.
........
r73065 | antoine.pitrou | 2009-05-30 23:39:25 +0200 (sam., 30 mai 2009) | 3 lines
The test for #5330 wasn't correct.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r73064 | antoine.pitrou | 2009-05-30 23:27:00 +0200 (sam., 30 mai 2009) | 4 lines
Issue #5330: C functions called with keyword arguments were not reported by
the various profiling modules (profile, cProfile). Patch by Hagen Fürstenau.
........
lnotab-based tracing is very complicated and isn't documented very well. There
were at least 3 comment blocks purporting to document co_lnotab, and none did a
very good job. This patch unifies them into Objects/lnotab_notes.txt which
tries to completely capture the current state of affairs.
I also discovered that we've attached 2 layers of patches to the basic tracing
scheme. The first layer avoids jumping to instructions that don't start a line,
to avoid problems in if statements and while loops. The second layer
discovered that jumps backward do need to trace at instructions that don't
start a line, so it added extra lnotab entries for 'while' and 'for' loops, and
added a special case for backward jumps within the same line. I replaced these
patches by just treating forward and backward jumps differently.
Most uses of PyCode_Addr2Line
(http://www.google.com/codesearch?q=PyCode_Addr2Line) are just trying to get
the line number of a specified frame, but there's no way to do that directly.
Forcing people to go through the code object makes them know more about the
guts of the interpreter than they should need.
The remaining uses of PyCode_Addr2Line seem to be getting the line from a
traceback (for example,
http://www.google.com/codesearch/p?hl=en#u_9_nDrchrw/pygame-1.7.1release/src/base.c&q=PyCode_Addr2Line),
which is replaced by the tb_lineno field. So we may be able to deprecate
PyCode_Addr2Line entirely for external use.
POP_JUMP_IF_{TRUE,FALSE} and JUMP_IF_{TRUE,FALSE}_OR_POP. This avoids executing
a POP_TOP on each conditional and sometimes allows the peephole optimizer to
skip a JUMP_ABSOLUTE entirely. It speeds up list comprehensions significantly.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r69811 | collin.winter | 2009-02-20 13:30:41 -0600 (Fri, 20 Feb 2009) | 2 lines
Issue 5176: special-case string formatting in BINARY_MODULO implementation. This shows a modest (1-3%) speed-up in templating systems, for example.
........
r69947 | jeffrey.yasskin | 2009-02-24 16:48:34 -0600 (Tue, 24 Feb 2009) | 3 lines
Tools/scripts/analyze_dxp.py, a module with some helper functions to
analyze the output of sys.getdxp().
........
This patch by Antoine Pitrou optimizes the bytecode for conditional branches by
merging the following "POP_TOP" instruction into the conditional jump. For
example, the list comprehension "[x for x in l if not x]" produced the
following bytecode:
1 0 BUILD_LIST 0
3 LOAD_FAST 0 (.0)
>> 6 FOR_ITER 23 (to 32)
9 STORE_FAST 1 (x)
12 LOAD_FAST 1 (x)
15 JUMP_IF_TRUE 10 (to 28)
18 POP_TOP
19 LOAD_FAST 1 (x)
22 LIST_APPEND 2
25 JUMP_ABSOLUTE 6
>> 28 POP_TOP
29 JUMP_ABSOLUTE 6
>> 32 RETURN_VALUE
but after the patch it produces the following bytecode:
1 0 BUILD_LIST 0
3 LOAD_FAST 0 (.0)
>> 6 FOR_ITER 18 (to 27)
9 STORE_FAST 1 (x)
12 LOAD_FAST 1 (x)
15 POP_JUMP_IF_TRUE 6
18 LOAD_FAST 1 (x)
21 LIST_APPEND 2
24 JUMP_ABSOLUTE 6
>> 27 RETURN_VALUE
Notice that not only the code is shorter, but the conditional jump
(POP_JUMP_IF_TRUE) jumps right to the start of the loop instead of going through
the JUMP_ABSOLUTE at the end. "continue" statements are helped
similarly.
Furthermore, the old jump opcodes (JUMP_IF_FALSE, JUMP_IF_TRUE) have been
replaced by two new opcodes:
- JUMP_IF_TRUE_OR_POP, which jumps if true and pops otherwise
- JUMP_IF_FALSE_OR_POP, which jumps if false and pops otherwise
on compilers that support it (notably: gcc, SunPro, icc), the bytecode
evaluation loop is compiled with a new dispatch mechanism which gives
speedups of up to 20%, depending on the system, on various benchmarks.
svn+ssh://pythondev@svn.python.org/python/trunk
........
r67494 | jeffrey.yasskin | 2008-12-02 22:46:45 -0800 (Tue, 02 Dec 2008) | 5 lines
Speed up Python (according to pybench and 2to3-on-itself) by 1-2% by caching
whether any thread has tracing turned on, which saves one load instruction in
the fast_next_opcode path in PyEval_EvalFrameEx(). See issue 4477.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r67666 | jeffrey.yasskin | 2008-12-08 10:55:24 -0800 (Mon, 08 Dec 2008) | 3 lines
Issue 4597: Fix several cases in EvalFrameEx where an exception could be
"raised" without setting x, err, or why to let the eval loop know.
........
r67685 | jeffrey.yasskin | 2008-12-09 23:35:02 -0800 (Tue, 09 Dec 2008) | 2 lines
Update Misc/NEWS for r67666.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r67666 | jeffrey.yasskin | 2008-12-08 10:55:24 -0800 (Mon, 08 Dec 2008) | 3 lines
Issue 4597: Fix several cases in EvalFrameEx where an exception could be
"raised" without setting x, err, or why to let the eval loop know.
........
r67685 | jeffrey.yasskin | 2008-12-09 23:35:02 -0800 (Tue, 09 Dec 2008) | 2 lines
Update Misc/NEWS for r67666.
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r67688 | amaury.forgeotdarc | 2008-12-11 00:22:49 +0100 (jeu., 11 déc. 2008) | 6 lines
#4559: When a context manager's __exit__() method returns an object whose
conversion to bool raises an exception, 'with' loses that exception.
Reviewed by Jeffrey Yasskin.
Already ported to 2.5, will port to 2.6 and 3.0
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r67688 | amaury.forgeotdarc | 2008-12-11 00:22:49 +0100 (jeu., 11 déc. 2008) | 6 lines
#4559: When a context manager's __exit__() method returns an object whose
conversion to bool raises an exception, 'with' loses that exception.
Reviewed by Jeffrey Yasskin.
Already ported to 2.5, will port to 2.6 and 3.0
........
svn+ssh://pythondev@svn.python.org/python/trunk
........
r67494 | jeffrey.yasskin | 2008-12-02 22:46:45 -0800 (Tue, 02 Dec 2008) | 5 lines
Speed up Python (according to pybench and 2to3-on-itself) by 1-2% by caching
whether any thread has tracing turned on, which saves one load instruction in
the fast_next_opcode path in PyEval_EvalFrameEx(). See issue 4477.
........
could be easily encountered under Windows in debug mode when exercising
the recursion limit checking code, due to bogus handling of recursion
limit when USE_STACKCHEK was enabled.
Reviewed by Amaury Forgeot d'Arc on IRC.
an 'except' clause), the exception __context__ would be reset to None.
This crases the interpreter if this precisely happens inside PyErr_SetObject.
- now the __context__ is properly preserved
- in any case, PyErr_SetObject now saves the current exc_value in a local variable, to
avoid such crashes in the future.
Reviewer: Antoine Pitrou.
Fixes Issue #874900: after an os.fork() call the threading module state is cleaned
up in the child process to prevent deadlock and report proper thread counts
if the new process uses the threading module.
PyUnicode_AsStringAndSize -> _PyUnicode_AsStringAndSize to mark
them for interpreter internal use only.
We'll have to rework these APIs or create new ones for the
purpose of accessing the UTF-8 representation of Unicode objects
for 3.1.