[issue40974] possible optimization: SHRINK_STACK(n)

Serhiy Storchaka added the comment: It increases the size of the eval loop. It can break optimizations which is performed by the C compiler only when the code size does not exceed some limits, and it can exceed the size of processor caches which can make execution less efficient. So there ar

[issue40974] possible optimization: SHRINK_STACK(n)

Change by Raymond Hettinger : -- nosy: +rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue40974] possible optimization: SHRINK_STACK(n)

Pablo Galindo Salgado added the comment: > less opcodes = faster evaluation Unfortunately, that is not always true as opcodes can have arbitrary complexity and there are very low-level effects that are relevant in the eval loop. Even if it is better, the improvement may not be worth burning

[issue40974] possible optimization: SHRINK_STACK(n)

Change by Batuhan Taskaya : -- nosy: +Mark.Shannon, pablogsal ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue40974] possible optimization: SHRINK_STACK(n)

New submission from SHRINK_STACK : context managers and except blocks generates multiple POP_TOPS constantly and maybe other cases which might lead generation of multiple POP_TOPS. A SHRINK_STACK(n) opcode would make things better (improvement on pyc size, less opcodes = faster evaluation).