Issue 1292625: use LIST_APPEND opcode for X.append() method calls (original) (raw)

Issue1292625

Created on 2005-09-16 07:14 by nnorwitz, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
list-append.diff nnorwitz,2005-09-16 07:14 v1.5
LIST_APPEND.diff nnorwitz,2005-09-28 05:55 last version
Messages (4)
msg48735 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2005-09-16 07:14
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 %
msg48736 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2005-09-16 08:12
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).
msg48737 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2005-09-27 21:34
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.
msg48738 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2005-09-28 05:50
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.
History
Date User Action Args
2022-04-11 14:56:13 admin set github: 42374
2005-09-16 07:14:32 nnorwitz create