Currently, functools.lru_cache implement own doubly-linked list.But it is inefficient than OrderedDict because each link node is GC object.So it may eat more memory and take longer GC time.I added two private C API for OrderedDict and make lru_cache use it.* _PyODict_LRUGetItem(): Similar to PyDict_GetItemWithHash() + od.move_to_end(last=True).* _PyODict_PopItem():  Similar to odict.popitem().Why I didn't implement C version of move_to_end() is to reduce lookup. _PyODict_LRUGetItem(key) lookup key once whileod[key]; od.move_to_end(key) lookup key twice.I'll benchmark it and report result here.

Current implementation (no news entry yet):https://github.com/methane/cpython/pull/10/files

This is a duplicate ofissue28239.

Ah, sorry, you use OrderedDict instead of just ordered dict. It should have different timing and memory consumption.

Hmm, it seems my implementation is 30% slower when many mishit scenario.Maybe, dict is faster than OrderedDict about massive insert/discard.  But I need to profile it.On the other hand, GC speed looks about 2x faster as expected.$ ./python -m perf compare_to master.json patched.json  -GSlower (5):- lru_1000_100: 217 ns +- 6 ns -> 302 ns +- 6 ns: 1.39x slower (+39%)- lru_10000_1000: 225 ns +- 4 ns -> 309 ns +- 2 ns: 1.37x slower (+37%)- lru_100_1000: 114 ns +- 5 ns -> 119 ns +- 1 ns: 1.05x slower (+5%)- lru_100_100: 115 ns +- 6 ns -> 119 ns +- 1 ns: 1.03x slower (+3%)- lru_1000_1000: 134 ns +- 6 ns -> 136 ns +- 1 ns: 1.02x slower (+2%)Faster (4):- gc(1000000): 98.3 ms +- 0.3 ms -> 37.9 ms +- 0.2 ms: 2.59x faster (-61%)- gc(100000): 11.7 ms +- 0.0 ms -> 5.10 ms +- 0.02 ms: 2.29x faster (-56%)- gc(10000): 1.48 ms +- 0.02 ms -> 1.04 ms +- 0.01 ms: 1.41x faster (-29%)- lru_10_100: 149 ns +- 6 ns -> 147 ns +- 2 ns: 1.02x faster (-2%)

I found odict.pop() and odict.popitem() is very inefficient becauseit look up key multiple times.odict seems not optimized well and very slow than dict in some area...I'll try to optimize it in holidays.

Please stop revising every single thing you look at.  The traditional design of LRU caches used doubly linked lists for a reason.  In particular, when there is a high hit rate, the links can be updated without churning the underlying dictionary.

FWIW, I'm the original author and designer of this code, so it would have been appropriate to assign this to me for sign-off on any proposed changes.

> FWIW, I'm the original author and designer of this code, so it would have> been appropriate to assign this to me for sign-off on any proposed changes.Not me (the C implementation)? ;-)

> Please stop revising every single thing you look at.  The traditional design of LRU caches used doubly linked lists for a reason.  In particular, when there is a high hit rate, the links can be updated without churning the underlying dictionary.I don't proposing removing doubly linked list; OrderedDict usesdoubly-linked list too, and I found no problem for most-hit scenario.On the other hand, I found problem of OrderedDict for most mis hitscenario.Now I think lru_cache's implementation is better OrderedDict.PyODict is slower than lru_cache's dict + linked list because ofhistorical reason (compatibility with pure Python implemantation.)So I stop trying to remove lru_cache's own implementation.I'll try to reduce overhead of lru_cache, by removing GC headerfrom link node.

PR-5008 benchmark:$ ./python -m perf compare_to master.json patched2.json -GFaster (9):- gc(1000000): 98.3 ms +- 0.3 ms -> 29.9 ms +- 0.4 ms: 3.29x faster (-70%)- gc(100000): 11.7 ms +- 0.0 ms -> 3.71 ms +- 0.03 ms: 3.14x faster (-68%)- gc(10000): 1.48 ms +- 0.02 ms -> 940 us +- 6 us: 1.57x faster (-36%)- lru_10_100: 149 ns +- 6 ns -> 138 ns +- 1 ns: 1.08x faster (-8%)- lru_100_100: 115 ns +- 6 ns -> 108 ns +- 1 ns: 1.07x faster (-6%)- lru_1000_1000: 134 ns +- 6 ns -> 127 ns +- 1 ns: 1.05x faster (-5%)- lru_100_1000: 114 ns +- 5 ns -> 108 ns +- 1 ns: 1.05x faster (-5%)- lru_1000_100: 217 ns +- 6 ns -> 212 ns +- 4 ns: 1.03x faster (-2%)- lru_10000_1000: 225 ns +- 4 ns -> 221 ns +- 5 ns: 1.02x faster (-2%)

LGTM.

New changeset3070b71e5eedf62e49b8e7dedab75742a5f67ece by INADA Naoki in branch 'master':bpo-32422: Reduce lru_cache memory usage (GH-5008)https://github.com/python/cpython/commit/3070b71e5eedf62e49b8e7dedab75742a5f67ece