Unneeded constants left during optimization

[kamek]

BPO	1589074
Nosy	@loewis, @rhettinger
Files	python-constants.txt

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2006-11-05.22:07:45.000>
created_at = <Date 2006-11-02.05:55:10.000>
labels = ['interpreter-core', 'type-feature']
title = 'Unneeded constants left during optimization'
updated_at = <Date 2006-11-05.22:07:45.000>
user = 'https://bugs.python.org/kamek'

bugs.python.org fields:

activity = <Date 2006-11-05.22:07:45.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2006-11-02.05:55:10.000>
creator = 'kamek'
dependencies = []
files = ['8281']
hgrepos = []
issue_num = 1589074
keywords = []
message_count = 6.0
messages = ['54929', '54930', '54931', '54932', '54933', '54934']
nosy_count = 3.0
nosy_names = ['loewis', 'rhettinger', 'kamek']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue1589074'
versions = []

[kamek]

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.

[kamek]

Logged In: YES
user_id=539453

Sorry, I rushed and missed the File Description field.
Should be "Interactive interpreter testcases".

[loewis]

Logged In: YES
user_id=21627

Would you like to work on a patch to fix this problem?

[rhettinger]

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.

[kamek]

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 :)

[loewis]

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.