what is the perfomance impact of have more than one layer? why not a big one layer instead of 2 smalls?

Having more layers decreases the amount of cache invalidation when cache fills up, but I'm still not sure how useful is that, the tradeoff is significative for layers > 2.

Should be keep it simple, this change make hashlru become too complicated.

@homeopatchy when you say the tradeoff is significant when layers > 2 - do you mean it's significantly faster or significantly slower?

also, would you mind proofing this with https://github.com/dominictarr/bench-lru

can you design a benchmark or other measurement that demonstrates the tradeoff?
I can imagine that it might amortize the cost of discarding the old layers, but on the other hand, now you have to look at N caches, which will be more expensive.

Yeah sorry for the confusion, I meant it's significantly slower. but I guess there could be a tradeoff a user may be willing to take when cached values are expensive to compute, or valuable for another reason. Understandably, bench-lru provides just test cases for raw speed benchmarking, I think a multi-layered hashlru could perform better than the others against a randomized set/get bench, but I haven't tested this yet.

Okay, I'm gonna leave this open until a case where this is faster can be demonstrated.

Here's the randomized benchmark which tests hashlru, the multilayer version and a couple of the fastest alternative lru cache implementations. They are all configured to hold 10x less entries than there are available. The multilayer version shows a small improvement, but in resume maybe this patch shouldn't be merged due the extra complexity added and the performance loss on more predictable use cases.

@homeopatchy since the difference is fairly small, we need to compare the standard deviations - check the bench.js file on master.