Thanks Benjamin ! Definitively worth a try...
Le 26/05/15 08:05, Benjamin Manes a écrit : > 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). > > https://github.com/ben-manes/caffeine/wiki/Benchmarks > >> 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. > > Cheers, > Ben > > On Mon, May 25, 2015 at 4:11 PM, Benjamin Manes <[email protected]> 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] http://osdir.com/ml/dev-directory-apache/2013-09/msg00038.html >> [2] http://osdir.com/ml/dev-directory-apache/2013-09/msg00008.html >> [3] https://github.com/ben-manes/caffeine >>
