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.

classification
Title: Unneeded constants left during optimization
Type: enhancement Stage:
Components: Interpreter Core Versions:
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: kamek, loewis, rhettinger
Priority: normal Keywords:

Created on 2006-11-02 05:55 by kamek, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
python-constants.txt kamek, 2006-11-02 05:55
Messages (6)
msg54929 - (view) Author: Daniel (kamek) Date: 2006-11-02 05:55
At some point, when generating the bytecode, the
parser/compiler pre-calculates operations on constants.
However, the old values, which are often not needed
anymore in the constants, are left there as garbage.

To keep this description from being lengthy, I'm
attaching a text file with several simple
demonstrations that serve as testcases.
msg54930 - (view) Author: Daniel (kamek) Date: 2006-11-02 05:58
Logged In: YES 
user_id=539453

Sorry, I rushed and missed the File Description field.
Should be "Interactive interpreter testcases".
msg54931 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-11-04 15:29
Logged In: YES 
user_id=21627

Would you like to work on a patch to fix this problem?
msg54932 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2006-11-05 20:39
Logged In: YES 
user_id=80475

I looked at this when constant folding was first introduced
and it did not seem worth doing because 1) it would be
somewhat complicated to implement (counting each time a
constant is used and renumbering all constant references
once a deletion occurs), 2) it would be hard to maintain, 3)
it would slow-down compilation, and 4) the potential benefit
is microscopic (saving a few bytes but not improving
execution speed).

Here's an example of the difficulty:

>>> def f():
	x = 3
	y = 3 + 4
	return x + y

>>> f.func_code.co_consts
(None, 3, 4, 7)

The constant folding for 3+4 introduces the 7 but cannot
easily know that the 3 is used elsewhere while the 4 is not.

Am reclassifying this as a feature request for a trivial
space optimization (there is no bug, the peepholer is
functioning as designed). This suggestion could be
implemented but (IMO) is not worth it.

msg54933 - (view) Author: Daniel (kamek) Date: 2006-11-05 21:12
Logged In: YES 
user_id=539453

loewis:
Sorry, I'm afraid I don't have enough knowledge on Python's
internals to work on it.

rhettinger:
Well, that's bad, but I did expect that; I agree the actual
benefits would be minimal, especially considering how
relatively rare this optimization occurs and how those
constants are often quite light on memory usage.
But what about intermediate constants (which we are sure
that aren't used elsewhere, like in 3 + 4 + 10)? Would it be
easier to get rid of them (or maybe reuse previously defined
constants when available)?

All in all, sorry for being too nitpicky. I know this isn't
any crucial issue :)
msg54934 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-11-05 22:07
Logged In: YES 
user_id=21627

kamek: with the current peephole pass, it wouldn't be easy
to eliminate intermediate constants. The peephole operates
on individual instructions, introducing a new constant each
time. That code would have to track what constants were
originally there and which ones are new, and then would also
have to take into account that the constant numbering must
not change (so you can always only eliminate the last
constant, unless you add an entire new pass that renumbers
all opcodes that refer to constants).

Closing this as "won't fix", then, as nobody seems to be
willing to work on it.

If this is ever attempted, I think the constant folding
should happen on the AST level, rather than on the bytecode
level.
History
Date User Action Args
2022-04-11 14:56:21adminsetgithub: 44188
2006-11-02 05:55:10kamekcreate