Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
Serhiy, do you think we could substitute the "self" instance of functools._lru_cache_wrapper object for the kw_mark? It already compares on identity, so it should be just a fast as the instance of object(). AFAICT, kwd_mark doesn't have to be unique across instances. To avoid creating a GC only circular reference, we could skip the INCREF, leaving the object weakly referencing itself. In bounded_lru_cache_wrapper(), the other state reference reference is in creating a new lru_list_elem. There are several things we can do about this. 1) move the expensive get_functools_state_by_type() inside the code block that creates new links, so that it won't affect a full cache. 2) create a per-instance variable that references the per-type lru_list_elem. This has the downside of making each lru_cache instance slightly larger. 3) prepopulate the lru_cache with maxsize links. This simplifies the code and makes it slightly faster but will waste spaces for use cases that never actually fill-up the cache lazily, also it slows down start-up time. Ideally, these PRs should be reverted for Python 3.10. AFAICT, no user of functools will benefit in any way from these changes. Presumably, that is why there are no tests. It is all cost and no benefit. BTW, the 6% timing is likely understated because the loop is executed entirely in L1 cache or the CPU's recent write cache rather than real world conditions where there is fierce competition of the limited 32kb L1 data cache. Just looking at the total number of sequentially dependent memory accesses, I expect that the actual cost is more than a third. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue40137> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
