Github user ben-manes commented on the issue:
https://github.com/apache/metron/pull/940
Caffeine doesn't allocate on read, so that would make sense. I saw a [25x
boost](https://github.com/google/guava/issues/2063#issuecomment-107169736)
(compared to
[current](https://github.com
Github user ben-manes commented on the issue:
https://github.com/apache/metron/pull/940
Interesting. Then I guess the size must trigger the read bottleneck as
larger than writes. Perhaps it is incurring a lot more GC overhead that causes
more collections? The CLQ additions requires
Github user ben-manes commented on the issue:
https://github.com/apache/metron/pull/940
Internally Guava uses a `ConcurrentLinkedQueue` and an `AtomicInteger` to
record its size, per segment. When a read occurs, it records that in the queue
and then drains it under the segment's lock
Github user ben-manes commented on the issue:
https://github.com/apache/metron/pull/940
Guava defaults to a `concurrencyLevel` of 4, given its age and a desire to
not abuse memory in low concurrent situations. You probably want to increase it
to 64 in a heavy workload, which has
Github user ben-manes commented on the issue:
https://github.com/apache/metron/pull/940
That makes sense. A uniform distribution will, of course, degrades all
policies to random replacement so the test is then about how well the
implementations handle concurrency. Most often caches
Github user ben-manes commented on the issue:
https://github.com/apache/metron/pull/940
Do you know what the hit rates were, for the same data set, between Guava
and Caffeine? The caches use different policies so it is always interesting to
see how the handle given workloads. As we
