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.

Author gvanrossum
Recipients Mark.Shannon, gvanrossum, python-dev, serhiy.storchaka, tomkpz
Date 2021-03-15.01:26:20
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1615771580.89.0.179612732673.issue42917@roundup.psfhosted.org>
In-reply-to
Content
I don't see what putting the limit back in this PR would give, but I do question that we need more block nesting, and this PR causes a lot of code churn (including a new API to create frames). It would be more convincing if you could actually point to a code generator that would benefit, rather than hand-waving "code generators might use it."

I'm also not sure that we'll see measurable benefits in terms of memory access locality. Have you tried to benchmark this? Even a micro-benchmark aiming to show there is *some* effect would be helpful.

At the same time I'm intrigued by Serhiy's idea, which could well reduce the size of the bytecode and the cost of instruction decoding by avoiding all dynamic block stack manipulation.

There are also other ideas floating about for improving memory locality related to the frame stack, e.g. putting the stack frames in an array instead of a linked list.
History
Date User Action Args
2021-03-15 01:26:20gvanrossumsetrecipients: + gvanrossum, Mark.Shannon, python-dev, serhiy.storchaka, tomkpz
2021-03-15 01:26:20gvanrossumsetmessageid: <1615771580.89.0.179612732673.issue42917@roundup.psfhosted.org>
2021-03-15 01:26:20gvanrossumlinkissue42917 messages
2021-03-15 01:26:20gvanrossumcreate