[issue13607] Move generator specific sections out of ceval.

Change by Serhiy Storchaka : -- resolution: -> out of date stage: patch review -> resolved status: pending -> closed ___ Python tracker ___

[issue13607] Move generator specific sections out of ceval.

Change by Serhiy Storchaka : -- status: open -> pending ___ Python tracker ___

[issue13607] Move generator specific sections out of ceval.

Serhiy Storchaka added the comment: The WHY_* codes are gone in 3.8 (see issue17611). Exception state was moved from frame to generator in 3.7 (see issue25612). Can some parts of the patch be applied to the current code? Or it is completely outdated? --

[issue13607] Move generator specific sections out of ceval.

Changes by Terry J. Reedy tjre...@udel.edu: -- versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___ ___

[issue13607] Move generator specific sections out of ceval.

Mark Shannon m...@hotpy.org added the comment: Why do the codes used internally by ceval have to be the same as those made public? Have you considered returning the exit code directly, rather than adding another field to frameobject? yieldfrom can be handled in a similar way to yield by

[issue13607] Move generator specific sections out of ceval.

Changes by Ron Adam ron3...@gmail.com: Removed file: http://bugs.python.org/file24047/f_why1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___

[issue13607] Move generator specific sections out of ceval.

Ron Adam ron3...@gmail.com added the comment: Updated patch with suggested changes. It also has a cleaned up fast_block_end section. Concerning speed. What happens is (as Tim and Raymond have pointed out) that we can make some things a little faster, in exchange for other things being a

[issue13607] Move generator specific sections out of ceval.

Ron Adam ron3...@gmail.com added the comment: I think the time benefits I saw are dependent on how the C code is compiled. So it may be different on different compilers or the same compiler with only a very minor change. Some of the things I've noticed... A switch is sometimes slower if it

[issue13607] Move generator specific sections out of ceval.

Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___ ___ Python-bugs-list

[issue13607] Move generator specific sections out of ceval.

Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___ ___ Python-bugs-list

[issue13607] Move generator specific sections out of ceval.

Meador Inge mead...@gmail.com added the comment: With the new patch I see no benefits on the same micro-benchmarks you posted (it is even slower for the smaller case) on a quad-core 64-bit F15 box: BEFORE: $ ./python -mtimeit def y(n): for x in range(n): yield x sum(y(10)) 100

[issue13607] Move generator specific sections out of ceval.

Nick Coghlan ncogh...@gmail.com added the comment: The thing that most appeals to me with this concept is moving closer to making it possible to experiment with generator-style functionality in *extension* modules (albeit extension modules that are coupled to private CPython APIs). So, for

[issue13607] Move generator specific sections out of ceval.

Changes by Ron Adam ron3...@gmail.com: Removed file: http://bugs.python.org/file23969/f_why.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___

[issue13607] Move generator specific sections out of ceval.

Ron Adam ron3...@gmail.com added the comment: New diff file. The main difference is I moved the saved why value to the tstate object instead of the frame object as why_exit. I'm not seeing the time savings now for some reason. Maybe the previous increase was a case of coincidental noise.

[issue13607] Move generator specific sections out of ceval.

Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___ ___ Python-bugs-list mailing list

[issue13607] Move generator specific sections out of ceval.

Changes by Terry J. Reedy tjre...@udel.edu: -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___ ___ Python-bugs-list

[issue13607] Move generator specific sections out of ceval.

Benjamin Peterson benja...@python.org added the comment: Seems mostly fine to me. -- assignee: - benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___

[issue13607] Move generator specific sections out of ceval.

New submission from Ron Adam ron3...@gmail.com: The following changes cleanup the eval loop and result in a pretty solid 2 to 3% improvement in pybench for me. And it is about 5% faster for long generators. * Change why enum type to int and #defines. And moved the why defines to opcode.h so

[issue13607] Move generator specific sections out of ceval.

Ron Adam ron3...@gmail.com added the comment: A simple test to show the difference. BEFORE: $ python3 -mtimeit def y(n): for x in range(n): yield x sum(y(10)) 10 loops, best of 3: 3.87 usec per loop $ python3 -mtimeit def y(n): for x in range(n): yield x sum(y(100)) 10

[issue13607] Move generator specific sections out of ceval.

Changes by Antoine Pitrou pit...@free.fr: -- nosy: +benjamin.peterson, ncoghlan stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13607 ___