[Python-ideas] Membership of infinite iterators

Koos Zevenhoven k7hoven at gmail.com
Thu Nov 2 08:00:26 EDT 2017

On Thu, Nov 2, 2017 at 1:41 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Thu, 2 Nov 2017 13:27:17 +0200
> Koos Zevenhoven <k7hoven at gmail.com> wrote:
> > ​There's a limit to how cheap the call to PyErr_CheckSignals() can be.
> As I
> > mentioned earlier, even just the fact that it's a C function call​ can be
> > too much.
> >
> > That's why, in the above, I used a new name PyErr_PROBE_SIGNALS() instead
> > of optimizing the existing PyErr_CheckSignals() –– turning
> > PyErr_CheckSignals() into a static inline function would change the ABI.
> I
> > also didn't call it PyErr_CHECK_SIGNALS() because the functionality is
> not
> > strictly equivalent to the existing function.
> Please.  If you want to replace PyErr_CheckSignals() with something
> faster, the first thing to do is to prove that PyErr_CheckSignals()
> *is* too expensive.

I believe Serhiy proved that by showing that his first patch did not have
negligible overhead for all cases. One might also write a C-implemented
fibonacci calculator or similar to prove the overhead is significant.

While I agree that there's a hint of premature optimization involved, my
justification for it is that I want people to be confident that when they
add the check, it's not going to slow down the loop significantly. Maybe
the fear of overhead is one of reasons for people to write uninterruptible
code. IMO, it should be made as easy as possible for the C programmer.


+ Koos Zevenhoven + http://twitter.com/k7hoven +
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20171102/a9f2698f/attachment.html>

More information about the Python-ideas mailing list