| 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) *  |
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) * |
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) * |
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. |
|
|