Guava cache overhead

[Jukka Zitting <ju...@gmail.com>]

Hi,

It seems like many of us have already hit the performance overhead of
the Guava cache, last examples in OAK-1042 and r1525946. It seems like
the tradeoffs made by Guava don't really work that well at least for
the benchmarks we're using. In a related discussion one of the Google
developers says [1]:

    "CacheBuilder was designed for server-side caching, where concurrency
    was a primary concern. It therefore trades off single-threaded and
    memory overhead in exchange for better multi-threaded behavior."

We do need concurrent access, but at least the caches in Segment- and
KernelNodeStore need to perform well also for high volumes of access
from a single thread. It sounds to me like Guava's target use case is
a lot of concurrent threads where each makes a few cache lookups,
whereas in our case it's more typically a few concurrent threads where
each makes a lot of cache lookups.

Thus it's probably a good idea for us to switch back to non-Guava
caching, while also keeping an eye at the concurrent access benchmarks
like the ones I posted about earlier. It would be a bad outcome if we
compromised concurrency for gains in single-threaded performance.

[1] http://stackoverflow.com/questions/9283070/bad-performance-with-guava-cache

BR,

Jukka Zitting