[Patches] [ python-Patches-1292625 ] use LIST_APPEND opcode for X.append() method calls
SourceForge.net
noreply at sourceforge.net
Wed Sep 28 07:50:24 CEST 2005
Patches item #1292625, was opened at 2005-09-16 00:14
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1292625&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core (C code)
Group: Python 2.5
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: use LIST_APPEND opcode for X.append() method calls
Initial Comment:
As discussed on python-dev here:
http://mail.python.org/pipermail/python-dev/2005-September/056396.html
This is a more complete version. It seems to speed up
code that makes heavy use of append by about 1.5 - 2.0 %
----------------------------------------------------------------------
>Comment By: Neal Norwitz (nnorwitz)
Date: 2005-09-27 22:50
Message:
Logged In: YES
user_id=33168
Response to Armin:
1) I think you are correct there is a problem with f(x.pp <
x.append). 2) I don't know if there was a discussion on the
semantic changes.
Response to Raymond:
The improvement is on the order of 50% for code that just
does L.append(). It was ~2% for Tim's program that is
referenced in the mail thread. ie, it was the total program
speed up, not just a simple test specifically for this feature.
I'm not real keen on this patch as it's too targetted. I
think the arguments could be overcome, however, time is
better spent on a more general solution.
----------------------------------------------------------------------
Comment By: Armin Rigo (arigo)
Date: 2005-09-27 14:34
Message:
Logged In: YES
user_id=4771
I vote -1 on this:
* these peephole transformations need a lot of care
to get perfectly right. For example, I think that
you are not checking that there is really a LOAD_XXX
between LOAD_ATTR and CALL_FUNCTION, which means that
you'll incorrectly match e.g. the bytecode of the line
'f(x.prepend < x.append)' and turn it into something
very broken.
* I don't remember seeing ever discussed the fact that
CALL_METHOD-style optimizations are a semantic
change: in 'x.append(f())', the LOAD_ATTR occurs
before the call to f(), whereas with the
optimization it occurs after. No sane code should
rely on that, but the language specification tends
to promize a left-to-right evaluation order unless
otherwise specified.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-09-16 01:12
Message:
Logged In: YES
user_id=80475
-0 on this one. It really needs a much larger improvement
(30% to 50%) to be worth it. The new ceval.c code for
LIST_APPEND will slightly slow-down the list comprehension
case that the opcode was originally designed for. Also, it
slows-down the peepholer with a string comparison test for
every attribute lookup making it the slowest and most
frequently executed code in the peepholer.
The implementation is limited to the simplest case,
x.append(y) and cannot handle general expressions such
x.append(y+y). It would likely be better to implement this
sort of transformation through AST when it is complete.
If it goes in anyway, be sure to add a test to make sure
descriptors still work (i.e. a non-data descriptor called
"append" for a user defined class).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1292625&group_id=5470
More information about the Patches
mailing list