This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Unsupported provider

classification
Title: Further simplify dict literal bytecode
Type: Stage:
Components: Interpreter Core Versions: Python 3.0
process
Status: closed Resolution: postponed
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: belopolsky, jafo, rhettinger
Priority: normal Keywords: patch

Created on 2008-02-27 04:42 by belopolsky, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
dict-literal.diff belopolsky, 2008-02-27 04:42 diff against py3k revision 61088
Messages (7)
msg63063 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-02-27 04:42
I am attaching a proof-of-concept patch that changes the bytecode 
generated from {1:1,2:2,3:3,4:4} from 

BUILD_MAP                4  
LOAD_CONST               2 (1)  
LOAD_CONST               2 (1)  
STORE_MAP             
LOAD_CONST               1 (2)  
LOAD_CONST               1 (2)  
STORE_MAP             
LOAD_CONST               4 (3)  
LOAD_CONST               4 (3)  
STORE_MAP             
LOAD_CONST               3 (4)  
LOAD_CONST               3 (4)  
STORE_MAP             

to

LOAD_CONST               1 (4)  
LOAD_CONST               1 (4)  
LOAD_CONST               2 (3)   
LOAD_CONST               2 (3)                                                    
LOAD_CONST               3 (2)                                        
LOAD_CONST               3 (2)                                         
LOAD_CONST               4 (1)  
LOAD_CONST               4 (1)  
BUILD_MAP                4  
 
and changes BUILD_MAP to behave similarly to BUILD_(SET|LIST|TUPLE) and 
consume 2*n items from the stack.

The advantage is more compact and faster bytecode and uniform treatment 
of BUILD_* instructions.
msg63064 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-02-27 05:03
Hmm, it looks like this was considered before (issue402227), but back 
then there were no set literals.  If stack-saving approach is better for 
dicts, it should be better for sets as well.  In any case, maybe it is 
time to revisit the issue and decide on the best way to treat both set 
and dict literals.  The truth may very well be that up to certain size 
it is better to build set/dict all at once from the stack, but past that 
size incremental insertion is better. The hybrid approach would be easy 
to implement.
msg63065 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-02-27 05:46
This changes semantics by executing all of the stores after the inputs 
are generated.  All of the pending item pairs get built-up on an ever-
growing stack instead of being consumed pairwise, never deepening the 
stack by more than two.
msg63071 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-02-27 13:29
I did not think of the insertion after creation change of semantics.  Do 
I understand that this is important when keys have custom 
comparison/hash methods with side-effects.  If it is important for the 
language to guarantee the create/insert order in building dict literals, 
it would be unfortunate if that order were specified differently for 
dict and set literals.

I will think some more about the stack issue.  There is a valid argument 
that large dict literals will be more common than large set literals, so 
the stack issue is more important for dicts.

BTW, what is the status of making set literal a frozen set proposal?
msg64143 - (view) Author: Sean Reifschneider (jafo) * (Python committer) Date: 2008-03-20 03:37
As addition thought is required by Alexander, I'm going to close this as
postponed and you can re-open it if after further consideration you
think it needs to be applied.  Probably would be good to discuss on
python-dev if you think it still needs to go forward though.
msg65169 - (view) Author: Alexander Belopolsky (belopolsky) * (Python committer) Date: 2008-04-08 15:32
Python-3000 discussion <http://mail.python.org/pipermail/python-
3000/2008-March/012753.html> did not reveal any opposition to the idea 
of batch processing of dict displays.  However, a compromise suggestion 
was made to  limit batches to 256 items 
<http://mail.python.org/pipermail/python-3000/2008-March/012829.html>.   
I don't think this type of micro-optimization belongs to the core.  A 
rare application that would benefit from limited size batch processing 
can do so explicitly using dict.update.

See also relevant discussion at issue2292 (starting at msg65111).

I believe this issue can be reopen.  I will submit documentation patch 
if the change is accepted in principle.
msg65173 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2008-04-08 15:54
-1   I don't think this is worth the semantic change.  The current 
approach doesn't require special cases for different dict sizes. The 
code/time savings is very small (seven bytes of opcodes per item get 
condensed by only one byte and the cost of one time around the eval-
loop is tiny in comparison to the cost of inserting a new dict entry).  
Besides, dict literals almost never occur in the inner-loops of time 
critical code. 

I recommend that this stay closed.  Better to aim for meaningful 
optimizations using the AST and avoid micro-optimizations that subtly 
change semantics.
History
Date User Action Args
2022-04-11 14:56:31adminsetgithub: 46450
2008-04-08 15:54:55rhettingersetmessages: + msg65173
2008-04-08 15:32:15belopolskysetmessages: + msg65169
2008-03-20 03:37:18jafosetstatus: open -> closed
nosy: + jafo
messages: + msg64143
priority: normal
assignee: rhettinger
resolution: postponed
2008-02-27 13:29:54belopolskysetmessages: + msg63071
2008-02-27 05:46:27rhettingersetnosy: + rhettinger
messages: + msg63065
2008-02-27 05:03:31belopolskysetmessages: + msg63064
2008-02-27 04:42:37belopolskycreate