Repository navigation
co_stacksize estimate can be highly off #68528
Description
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 2018-01-11.19:28:17.793>
created_at = <Date 2015-05-31.18:29:54.905>
labels = ['interpreter-core', '3.7', 'performance']
title = 'co_stacksize estimate can be highly off'
updated_at = <Date 2018-01-11.19:28:17.792>
user = 'https://github.com/arigo'bugs.python.org fields:
activity = <Date 2018-01-11.19:28:17.792>
actor = 'serhiy.storchaka'
assignee = 'none'
closed = True
closed_date = <Date 2018-01-11.19:28:17.793>
closer = 'serhiy.storchaka'
components = ['Interpreter Core']
creation = <Date 2015-05-31.18:29:54.905>
creator = 'arigo'
dependencies = []
files = []
hgrepos = []
issue_num = 24340
keywords = ['patch']
message_count = 8.0
messages = ['244552', '295118', '295119', '295122', '305677', '309346', '309347', '309733']
nosy_count = 7.0
nosy_names = ['nascheme', 'pitrou', 'benjamin.peterson', 'Arfrever', 'methane', 'serhiy.storchaka', 'yselivanov']
pr_nums = ['1938', '5076']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'resource usage'
url = 'https://bugs.python.org/issue24340'
versions = ['Python 3.7']
Activity
arigo commentedon May 31, 2015
The computation of
co_stacksize' by the compiler is known to give only an upper bound estimate. http://bugs.python.org/issue1754094 is an example of fixing a "leak" where every repetition of a statement makesco_stacksize' bigger by 1. However, in the whole 3.x series (from at least 3.2), the following simple code, which at runtime requires about 4 or 5 stack slots, leaks 14(!) slots for every `try:' block. Maybe this should be improved to reduce the extreme size of the leak.i.e. any function that is big enough to contain 6 try: blocks in sequence will have its stack size overestimated by about 70.
serhiy-storchaka commentedon Jun 4, 2017
PR 1938 tries to balance the stack effect computation for try/except and try/finally. I'm not sure that it is worth backporting.
Noised Antoine and Benjamin as people related to bpo-3021.
pitrou commentedon Jun 4, 2017
I'm against backporting performance improvements which don't fix a severe regression.
serhiy-storchaka commentedon Jun 4, 2017
This isn't so easy. Seems the simplest way to solve this issue is implementing bpo-17611.
nascheme commentedon Nov 6, 2017
The WIP pull request PR# 2827 seems to help. The following code prints 86 on python3.6 and 25 with PR 2827 applied.
serhiy-storchaka commentedon Jan 1, 2018
With PR 5076 the result of the above example is 10.
serhiy-storchaka commentedon Jan 1, 2018
Tests originally based on Antoine's tests added for PR 2827.
serhiy-storchaka commentedon Jan 9, 2018
New changeset d4864c6 by Serhiy Storchaka in branch 'master':
bpo-24340: Fix estimation of the code stack size. (bpo-5076)
d4864c6