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 nascheme
Recipients Demur Rumed, Mark.Shannon, benjamin.peterson, christian.heimes, mark.dickinson, nascheme, ncoghlan, pitrou, rhettinger, serhiy.storchaka, trent
Date 2017-12-29.05:26:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1514525205.86.0.213398074469.issue17611@psf.upfronthosting.co.za>
In-reply-to
Content
I wonder if I should drop PR 4682.  I spent some more time working on it today.  I switched to the same scheme as Serhiy for the no-exception case, i.e. push a single NULL value, rather than six NULLs.  In ceval, we need to handle the non-exception case specially anyhow so I think it better to avoid the "stack churn".  With the micro-benchmarks that Serhiy posted, PR 4682 is as fast or slightly faster than PR 5006.  Doesn't really matter in real code though.

I did not push my latest changes as I did not fix the frame.f_lineno issue yet.  I think it is fixable without major changes.  Should I bother though?  Is there some other reason to prefer duplicating the final bodies rather than using a subroutine jump (as in 5006)?  A very minor speedup is not worth it I think because the compiler is a bit more complicated.  The settrace logic is more complicated too.
History
Date User Action Args
2017-12-29 05:26:45naschemesetrecipients: + nascheme, rhettinger, mark.dickinson, ncoghlan, pitrou, christian.heimes, benjamin.peterson, trent, Mark.Shannon, serhiy.storchaka, Demur Rumed
2017-12-29 05:26:45naschemesetmessageid: <1514525205.86.0.213398074469.issue17611@psf.upfronthosting.co.za>
2017-12-29 05:26:45naschemelinkissue17611 messages
2017-12-29 05:26:45naschemecreate