[Python-ideas] PEP draft: context variables

[Koos Zevenhoven]

On Fri, Oct 13, 2017 at 2:07 AM, Stefan Krah <stefan at bytereef.org> wrote:

[..]

> So the decimal examples can be helpful for understanding, but (except
> for the performance issues) shouldn't be the centerpiece of the
> discussion.
>
>
> Speaking of performance, I have seen that adressed in Koos' PEP at all.
> Perhaps I missed something.
>

​Indeed I do mention performance here and there in the PEP 555 draft.
Lookups can be made fast and O(1) in most cases. Even with the simplest
unoptimized implementation, the worst-case lookup complexity would be O(n),
where n is the number of assignment contexts entered after the one which is
being looked up from (or in other words, nested inside the one that is
being looked up from). This means that for use cases where the relevant
context is entered as the innermost context level, the lookups are O(1)
even without any optimizations.

It is perfectly reasonable to make an implementation where lookups are
*always* O(1). Still, it might make more sense to implement a half-way
solution with "often O(1)", because that has somewhat less overhead in case
the callees end up not doing any lookups.

For synchronous code that does not use context arguments and that does not
involve generators, there is absolutely *zero* overhead.

For code that uses generators, but does not use context arguments, there is
virtually no overhead either. I explain this in terms of C code in

https://mail.python.org/pipermail/python-ideas/2017-October/047292.html

In fact, I might want to add a another Py_INCREF and Py_DECREF per each
call to next/send, because the hack to defer (and often avoid) the
Py_INCREF of the outer stack would not be worth the performance gain. But
that's it.

––Koos


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