getbadBlocks does get hit quite often by some CLs, about once every block or so, i think.
It does make sense to limit output to 100 blocks in the LRU, but reading the whole table on every call doesn't make sense. There should be an in-memory cache. Assuming there are about 1000 bad blocks, it's a 1000 sequential mdbx reads - that is not bad as such, but only if it's called every block
In accessors_chain tho, i don't see a natural point to include this LRU cache
It may help to add another table with blockNum + hash -> {}

getbadBlocks does get hit quite often by some CLs, about once every block or so, i think. It does make sense to limit output to 100 blocks in the LRU, but reading the whole table on every call doesn't make sense. There should be an in-memory cache. Assuming there are about 1000 bad blocks, it's a 1000 sequential mdbx reads - that is not bad as such, but only if it's called every block In accessors_chain tho, i don't see a natural point to include this LRU cache It may help to add another table with blockNum + hash -> {}

that's interesting. I thought it was just one-off queries by the user. Is there a reference which I can see about CL calling getBadBlocks?
If last 100 blocks is good enough, I think LRU cache is enough optimization. Adding new table is useful only if there are large number of bad blocks, and the assumption is that there aren't.

getbadBlocks does get hit quite often by some CLs, about once every block or so, i think. It does make sense to limit output to 100 blocks in the LRU, but reading the whole table on every call doesn't make sense. There should be an in-memory cache. Assuming there are about 1000 bad blocks, it's a 1000 sequential mdbx reads - that is not bad as such, but only if it's called every block In accessors_chain tho, i don't see a natural point to include this LRU cache It may help to add another table with blockNum + hash -> {}

that's interesting. I thought it was just one-off queries by the user. Is there a reference which I can see about CL calling getBadBlocks? If last 100 blocks is good enough, I think LRU cache is enough optimization. Adding new table is useful only if there are large number of bad blocks, and the assumption is that there aren't.

I think you will see those hits by running against a CL like lighthouse, nimbus, or teku against any network. You can also run a kurtosis env. Some of the CLs might also be optimizing on their side how often they call for this json resp, but in the worst case it could be bad.

@somnathb1 added cache to store the heap; it'll return the sorted values when queried.