PEP draft: context variables
Yury Selivanov wrote: [generators and decimal]
I also don't recall any single feature request to change the tls-context either for generators or for coroutines. Generators can quickly turn into a labyrinth, and that's not good for numerical code, which already has enough of its own complexities. 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. Stefan Krah
On Fri, Oct 13, 2017 at 2:07 AM, Stefan Krah <stefan@bytereef.org> wrote: [..]
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 +
On Fri, Oct 13, 2017 at 2:07 AM, Stefan Krah <stefan@bytereef.org> wrote: [..]
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 +
participants (2)
-
Koos Zevenhoven -
Stefan Krah