<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Fri, Oct 13, 2017 at 2:07 AM, Stefan Krah </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:stefan@bytereef.org" target="_blank">stefan@bytereef.org</a>></span><span style="font-family:arial,sans-serif"> wrote:</span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif"><br></span></div><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">[..]</span></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So the decimal examples can be helpful for understanding, but (except<br>
for the performance issues) shouldn't be the centerpiece of the<br>
discussion.<br>
<br>
<br>
Speaking of performance, I have seen that adressed in Koos' PEP at all.<br>
Perhaps I missed something.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:monospace,monospace">​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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">For synchronous code that does not use context arguments and that does not involve generators, there is absolutely *zero* overhead. </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">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</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default"><font face="monospace, monospace"><a href="https://mail.python.org/pipermail/python-ideas/2017-October/047292.html">https://mail.python.org/pipermail/python-ideas/2017-October/047292.html</a></font><br></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">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.</font></div><div class="gmail_default"><font face="monospace, monospace"><br></font></div><div class="gmail_default"><font face="monospace, monospace">––Koos</font></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div><br></div></div>-- <br><div class="gmail-m_1773629107472793173gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>