Pablo Galindo Salgado <pablog...@gmail.com> 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 another opcode, 
especially since the new opcode won't replace POP_TOP (so we need to deal with 
both).

Without evaluating the tradeoffs and how it plays into the current status quo I 
have some initial questions:

- What is the performance improvement of the patch that you propose? Could you 
run the pyperformance benchmark suite to have some numbers? 

- How many opcodes less are we talking about? What is the size before and after 
the suggested change in the stdlib pyc files?

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue40974>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to