LRU cache utility

[chfast]

Adds generic single-threaded implementation of
the least recently used (LRU) cache.

This is to be used to cache the code and code analysis.

[codecov]

Codecov Report

Attention: Patch coverage is 72.96296% with 73 lines in your changes missing coverage. Please review.

Project coverage is 93.96%. Comparing base (9d28979) to head (1200c41).

Files with missing lines	Patch %	Lines
test/internal_benchmarks/lru_cache_bench.cpp	0.00%	70 Missing ⚠️
lib/evmone/lru_cache.hpp	93.93%	2 Missing ⚠️
test/unittests/lru_cache_test.cpp	99.40%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1090      +/-   ##
==========================================
- Coverage   94.29%   93.96%   -0.33%     
==========================================
  Files         159      162       +3     
  Lines       17325    17595     +270     
==========================================
+ Hits        16337    16534     +197     
- Misses        988     1061      +73     

Flag	Coverage Δ
eof_execution_spec_tests	15.67% <0.00%> (-0.25%)	⬇️
ethereum_tests	26.48% <0.00%> (-0.42%)	⬇️
ethereum_tests_silkpre	18.66% <0.00%> (-0.32%)	⬇️
execution_spec_tests	20.78% <0.00%> (-0.33%)	⬇️
unittests	88.80% <73.50%> (-0.24%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
test/unittests/lru_cache_test.cpp	99.40% <99.40%> (ø)
lib/evmone/lru_cache.hpp	93.93% <93.93%> (ø)
test/internal_benchmarks/lru_cache_bench.cpp	0.00% <0.00%> (ø)

[rodiazet]

I sadly can't complain about anything. Let's ask Copilot then . :)

[gumb0]

Would it be possible/better to store values in the map entries? Then there'd be just one link LRUEntry => MapNode.
Now it's double-direction: LRUEntry::key => MapNode::key and MapNode::value -> LRUEntry

[gumb0]

Ah I see a comment below that there's no performance difference. But it seems more convoluted to me.

[chfast]

Yes, this is possible. Then the LRU list has only the pointer/reference/iterator to the map. And the map is Key => (LRUIterator, Value).

I'm kind of on your side here, but because the performance difference was negligible I decided to keep the "classic" layout for now. There is also small nuance: you cannot have std::list<const Key&> so you need to wrap the reference or use a pointer.

This is to be revisited in case we are going to use intrusive list and/or map iterators.

[gumb0]

Nit: the name kinda leaks internal representation (order of elements in the list). Maybe better something like touch(), use(), access() ?

[gumb0]

Actually I didn't notice it's a private method, then it's fine

[chfast]

I think I thought about it, e.g. naming it bump_usage(). In the end I decided not be because we also use lru_list_ directly in other places. E.g. we should also replace ru_list_.emplace with something like new_use()?

The main motivation was to wrap splice() which takes me usually some time to figure out.

[chfast]

I probably should mention O(1) get/put complexity.

[chfast]

I think I thought about it, e.g. naming it bump_usage(). In the end I decided not be because we also use lru_list_ directly in other places. E.g. we should also replace ru_list_.emplace with something like new_use()?

The main motivation was to wrap splice() which takes me usually some time to figure out.

[chfast]

Yes, this is possible. Then the LRU list has only the pointer/reference/iterator to the map. And the map is Key => (LRUIterator, Value).

I'm kind of on your side here, but because the performance difference was negligible I decided to keep the "classic" layout for now. There is also small nuance: you cannot have std::list<const Key&> so you need to wrap the reference or use a pointer.

This is to be revisited in case we are going to use intrusive list and/or map iterators.