directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Manes <>
Subject Re: [Mavibot] Need for a cache to replace the WeakReferences...
Date Tue, 26 May 2015 06:05:20 GMT
I am not subscribed to the list and it seems that responses do not
reply-all, so I'll watch the list and respond indirectly. Please reply-all
if you want my immediate feedback.

Emmanuel L├ęcharny wrote:
> 7x faster than? do you have comparison between caffeine and ehcache ?

6-7.5x faster than Ehcache v2.10 with a 100% hit rate using a Zipf
distribution, where the multiplier depends on the read/write ratio. This is
on a 4-core laptop and while I have every reason to believe that Caffeine
should scale even better on a server-class machine, I have not yet
validated that claim.

You are welcome to check the benchmarks for any mistakes. It can be run
with the command ./gradles jmh -PincludePattern=GetPutBenchmark and the
report is under caffeine/build/reports/jmh/human.txt. All caches use LRU
eviction with no other features enabled (no weak references, listeners,
expiration, etc).

> it seems like cafeine is using weak-references (keys automatically
wrapped in weak references)

That is a configuration option, not a requirement, and I agree that GC
based caching is not ideal. It would in fact invalidate a micobenchmark and
is not enabled in the one listed above. However there is no one size fits
all scenario in caching so many options are available for developers to
choose from. Caffeine uses code generation so that cache entries contain
only the fields required for that cache configuration.

Kiran Ayyagari wrote:
> does Caffeine depend on any other libraries

It uses JSR-305 annotations (e.g. @Nonnull) for documentation / static
analysis. That is currently used in compile scope, but could be moved to
provided scope as it is not required at runtime (the byte code is ignored).
I left it as compile scope for Scala users, as I haven't checked whether an
old compiler bug was fixed that caused scalac fail unless users explicitly
added it back in.

The cache has a dependency on Caffiene's tracing api, which will no-op
unless an implementation is discovered (via a ServiceLocator). The tracing
api has no dependencies.

The other modules are optional (guava, jsr107 jcache, async-tracer,
simulator). These modules do have external dependencies, but most
application's shouldn't include them.


On Mon, May 25, 2015 at 4:11 PM, Benjamin Manes <> wrote:

> I stumbled upon an old thread [1] regarding Mavibot's cache experiments.
> In that thread the project was moving away from weak reference based
> caching and had poor performance with Ehcache. A follow up discussion [2]
> mentioned experimenting with ConcurrentLinkedHashMap (my old project), but
> drops off before describing the results. As it appears Ehcache is used, it
> is not clear whether the performance problems were resolved or deemed not
> fixable.
> In case there is still a bottleneck in the caching layer you may be
> interested in my Java 8 caching project, Caffeine [3]. My benchmarks show
> it to be 7x faster on a 4-core machine and should scale better as the CPU
> count increases.
> Hope that helps,
> Ben
> [1]
> [2]
> [3]

View raw message