[issue2459] speedup for / while / if with better bytecode

Mark Lawrence added the comment: As a lot of work has gone into this it saddens me to see it languishing. Surely if Python performance is to be improved the bytecode for conditionals and loops is one of the places if not the place to do it? Are there any names missing from the nosy list that

[issue2459] speedup for / while / if with better bytecode

Christian Heimes added the comment: Is this enhancement still relevant? -- nosy: +christian.heimes status: open -> languishing versions: +Python 3.3, Python 3.4 -Python 3.1 ___ Python tracker ___

[issue2459] speedup for / while / if with better bytecode

Changes by Giampaolo Rodola' : -- nosy: +giampaolo.rodola ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue2459] speedup for / while / if with better bytecode

Changes by Daniel Stutzbach : -- nosy: +stutzbach ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue2459] speedup for / while / if with better bytecode

Dirkjan Ochtman added the comment: Is this still relevant / will it get some love in the future? -- nosy: +djc ___ Python tracker ___

[issue2459] speedup for / while / if with better bytecode

Jeffrey Yasskin added the comment: Hold off on reviewing this. There's one bug around the peepholer not turning itself off when line numbers skip by more than 127, and another around the traceback generator still assuming line numbers are unsigned. I'll post another patch when those are fixed an

[issue2459] speedup for / while / if with better bytecode

Jeffrey Yasskin added the comment: No particular reason for cPickle. It sometimes shows when we've caused problems by increasing the code size, and shows the size of any random effects that the compiler causes by moving code around. Could you double-check the patch to see if I did anything dumb?

[issue2459] speedup for / while / if with better bytecode

Antoine Pitrou added the comment: > I've updated for_iter.patch to the latest trunk, merging in issue 4715. > I also changed tracing a bit so that the first line of a loop doesn't > get traced twice in the first iteration, and added to test_dis to check > that decreasing line numbers work there.

[issue2459] speedup for / while / if with better bytecode

Jeffrey Yasskin added the comment: I've updated for_iter.patch to the latest trunk, merging in issue 4715. I also changed tracing a bit so that the first line of a loop doesn't get traced twice in the first iteration, and added to test_dis to check that decreasing line numbers work there. Revie

[issue2459] speedup for / while / if with better bytecode

Antoine Pitrou added the comment: > If you don't have the bandwidth to integrate 4715 into this patch, I > can do that, if you want. Collin, that would be very nice from you. You could also apply Jeffrey's naming suggestions in #4715. Thanks! Antoine. ___

[issue2459] speedup for / while / if with better bytecode

Collin Winter added the comment: On Fri, Feb 13, 2009 at 3:23 PM, Collin Winter wrote: > On Fri, Feb 13, 2009 at 10:37 AM, Antoine Pitrou > wrote: >> Before committing I want to know what to do with the new jump opcodes, >> with respect to the alternative proposal I've made in #4715. >> Ideal

[issue2459] speedup for / while / if with better bytecode

Collin Winter added the comment: On Fri, Feb 13, 2009 at 10:37 AM, Antoine Pitrou wrote: > > Antoine Pitrou added the comment: > > Hello Collin, > > Thanks for taking a look. > >> I don't see the changes to the lnotab format being a roadblock; just >> mention it in NEWS. Likewise, the pure-Pyt

[issue2459] speedup for / while / if with better bytecode

Antoine Pitrou added the comment: Hello Collin, Thanks for taking a look. > I don't see the changes to the lnotab format being a roadblock; just > mention it in NEWS. Likewise, the pure-Python compiler package shouldn't > be a high priority; your changes to that package look good enough. Well

[issue2459] speedup for / while / if with better bytecode

Collin Winter added the comment: I don't see the changes to the lnotab format being a roadblock; just mention it in NEWS. Likewise, the pure-Python compiler package shouldn't be a high priority; your changes to that package look good enough. I'm seeing encouraging speed-ups out of this (with gc

[issue2459] speedup for / while / if with better bytecode

Changes by Armin Rigo : -- nosy: -arigo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue2459] speedup for / while / if with better bytecode

Raymond Hettinger added the comment: I would like to see this go forward. It looks promising. ___ Python tracker ___ ___ Python-bugs-list mail

[issue2459] speedup for / while / if with better bytecode

Antoine Pitrou added the comment: Here is an updated patch against trunk. To be honest I don't think it has a lot of future: - it changes the lnotab format (to allow negative offsets) - it rewrites the buggy block reordering code in the pure Python compiler package, but nobody seems interested i

[issue2459] speedup for / while / if with better bytecode

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9829/loops3.patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue2459] speedup for / while / if with better bytecode

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9832/loops4.patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue2459] speedup for / while / if with better bytecode

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9863/loops5.patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue2459] speedup for / while / if with better bytecode

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9870/loops6.patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue2459] speedup for / while / if with better bytecode

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file9871/loops7.patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue2459] speedup for / while / if with better bytecode

Changes by Antoine Pitrou : Removed file: http://bugs.python.org/file10147/loops8.patch ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue2459] speedup for / while / if with better bytecode

Antoine Pitrou added the comment: The patches don't apply cleanly anymore, I'll regenerate a new one. ___ Python tracker ___ ___ Python-bugs-li

[issue2459] speedup for / while / if with better bytecode

Antoine Pitrou added the comment: > Reminder, make sure we can still break out of a "while 1: pass". Yes, the patch takes care of that. ___ Python tracker ___ ___

[issue2459] speedup for / while / if with better bytecode

Raymond Hettinger added the comment: Reminder, make sure we can still break out of a "while 1: pass". -- nosy: +rhettinger versions: +Python 2.7, Python 3.1 -Python 2.6 ___ Python tracker __

[issue2459] speedup for / while / if with better bytecode

Changes by Collin Winter : -- nosy: +collinwinter ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.py

[issue2459] speedup for / while / if with better bytecode

Χρήστος Γεωργίου (Christos Georgiou) <[EMAIL PROTECTED]> added the comment: A pointer to previous (minor) research: http://groups.google.com/group/comp.lang.python/browse_frm/thread/72505e3cb6d9cb1a/e486759f06ec4ee5 esp. after Terry Reedy's post -- nosy: +tzot

[issue2459] speedup for / while / if with better bytecode

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Finally I had to slightly change the lnotab format to have the right tracing semantics: the change is that line number increments are now signed bytes rather than unsigned. Still, there is a small change in tracing behaviour (see test_trace.p