On Tue, Oct 17, 2017 at 12:51 PM, Nathaniel Smith <n...@pobox.com> wrote:
> On Oct 17, 2017 11:25 AM, "Guido van Rossum" <gu...@python.org> wrote: > > > In short, I really don't think there's a need for context variables to be > faster than instance variables. > > > There really is: currently the cost of looking up a thread local through > the C API is a dict lookup, which is faster than instance variable lookup, > and decimal and numpy have both found that that's already too expensive. > (At first I found this hard to believe, but then I realized that decimal and numpy presumably access these from C code where a typical operation like Decimal.__add__ is much faster than a dict lookup. So point taken.) > Or maybe you're just talking about the speed when the cache misses, in > which case never mind :-). > I'm happy to support caching the snot out of this, but it seems we agree that the "semantics" can be specified without taking the caching into account, and that's what I'm after. I presume that each ContextVar object will have one cached value? Because that's what PEP 550 currently specifies. Surely it wouldn't be hard for a direct __setitem__ (or __delitem__) call to cause the cache to be invalidated, regardless of whether the affected context is a *current* context or not (a bunch of different approaches suggest themselves).Oother mutating methods can be implemented in terms of __setitem__ (or __delitem__), and I don't care for them to be as fast as a cached lookup. -- --Guido van Rossum (python.org/~guido)
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
