Clojure JIRA

[CCACHE-26] hit function in LRU cache can give funny results

Wed, 22 Aug 2012 21:06:13 -0500

A common-sense usage in caches is hit/get. But if I naively do this to an LRUCache, without checking first for the presence of the key, I can break the limit.

(-> (cache/lru-cache-factory {} :threshold 2)
(cache/hit :x)
(cache/hit :y)
(cache/hit :z)
(assoc :a 1)
(assoc :b 2)
(assoc :c 3)
(assoc :d 4)
(assoc :e 5))

; {:e 5, :d 4, :c 3, :b 2, :a 1}

[CCACHE-11] Add eviction implementation to LIRSCache

Thu, 8 Dec 2011 14:38:50 -0600

The evict method in the ProtocolCache needs implementation for LIRSCache. I will start initially with a single key eviction method to start. The evict method would form the basis for the associative dissoc which in turn forms the basis for proper limited seeding. LIRS poses an additional complication due to its dual limit lists. Currently only the BasicCache impl has evict.

[CCACHE-16] Benchmark v0.5.x against Google Guava

Fri, 16 Dec 2011 08:55:39 -0600

Perform some tests and benchmarks of core.cache and Google Guava's com.google.common.cache library.

[CCACHE-17] Create function backed cache

Mon, 19 Dec 2011 07:29:30 -0600

A cache implementation that is backed by a function that performs some action on a cache miss could serve as a front for any of the existing cache impls.

[CCACHE-15] It appears that TTL cache exhibits quadratic performance (+ its evict is buggy)

Thu, 15 Dec 2011 12:21:46 -0600

The library looks useful, thanks!

I looked at the code, and unless I'm mistaken, every cache miss seems to result in a full pass over the entire cache to evict old entries. The performance implications of this would be unacceptable for my target application. Replacing the TTL data structure with a persistent analog of a LinkedHashMap and using a take-while instead could fix this problem.

Also, evict seems to pass the cache in twice, rather than the cache and the TTL...

[CCACHE-20] Add some examples to github page

Sun, 19 Feb 2012 18:24:14 -0600

Could you add some examples on how to use core.cache to github readme?

[CCACHE-27] Missing LU and LRU is linear complexity - performance

Wed, 12 Sep 2012 09:27:56 -0500

Profiling some code with YourKit showed a hotspot in cache statistics on (miss) for LU and LRU caches.

Basically two issues: (count (keys {....})) is a count of a seq, not efficient. Replaced with a count of the map.

Secondly, (apply f anything) is slow. Profiler showed that the (apply min-key) was really slow. This is mitigated by using a c.d.priority-map instead. On a priority-map, (ffirst {}) or (first (peek {}).

Also inverted the logic for threshold comparison. Since there is a (build-leastness-queue) that populates statistics, should caches should favor codepaths for the state of being full all the time?

[CCACHE-29] Is IPersistentCollection definition of cons correct?

Sun, 18 Nov 2012 15:44:43 -0600

Here's the definition of `cons` for caches:

clojure.lang.IPersistentCollection
(cons _# elem#
(clojure.core/cons ~base-field elem#))

This seems wrong to me. Note first that the arguments to `clojure.core/cons` are in the wrong order. As a result, the result of (for example) conj is incorrect. Consider this:

user=> (def starts-with-a (cache/fifo-cache-factory {:a 1} :threshold 3))

#'user/starts-with-a
user=> starts-with-a
{:a 1}
user=> (conj starts-with-a [:c 3])
({:a 1} :c 3)

Even if the argument order was correct, the result would still be a sequence rather than the type of the base field. I think you want something more like

clojure.lang.IPersistentCollection
(cons this# elem#
(apply assoc this# elem#))

After all, this particular collection is an IPersistentMap, so its `conj` and `into` behavior should be the same as other objects for which `map?` is true.

[CCACHE-30] make-reference need not be dynamic

Sat, 9 Feb 2013 06:26:33 -0600

It looks like make-reference was made dynamic to support multiple clojure versions. Rebinding make-reference is really only needed for tests, and it would be a shame if making it dynamic causes performance issues.

Perhaps it is not enough of a performance issue to worry about. Otherwise, it might be possible to work around it. Perhaps directly pasting in and using the with-redefs macro, or something similar?

[CCACHE-28] SoftCache NullPointerException in has? with many threads

Sat, 9 Feb 2013 06:27:03 -0600

"cell" can be null on this call to SoftReference.get():
https://github.com/clojure/core.cache/blob/master/src/main/clojure/clojure/core/cache.clj#L501

If the cache did not contain "item" in the call to (get cache item) in the let binding, but another thread pre-empts and adds it before the subsequent call to contains?, we'll attempt to call .get() on nil.

Would it perhaps be sufficient to just check whether cell is nil instead of calling contains? in the check on the previous line?

[CCACHE-14] Asynchronous Cache Support

Tue, 13 Dec 2011 16:33:21 -0600

If people start implementing the cache protocol on top of external caches: Memcache, Redis, or others, an async version could make sense.

I started toying with an AsyncCacheProtocol which for all functions returning values would take two arities, a standard one which would return an instance of IRef, a second one which would take an extra callback argument to be called with the results. This doesn't solve everything though and async versions of LRU and friends would have to be implemented.

The alternative would be to have additional calls in CacheProtocol, such as async-has? async-lookup which would implement the 2 arity semantics and then rely on the fact that the underlying cache respects some sort of async semantics, since we cannot do that with Associative, maybe another middleman protocol CacheStorage could be used, this way, all external cache providers would have to do is implement a CacheProvider with optional asynchronous support.

I hope at least part of this makes sense.

[CCACHE-18] Explore JSR 107- Java Temporary Caching API

Mon, 19 Dec 2011 07:23:32 -0600

Is this relevant to core.cache? And many other questions answered.

<http://jcp.org/en/jsr/detail?id=107>