核心.cache中LRU和LU缓存的问题

Question

我正在使用core.cache，想知道为什么以大阈值和没有初始数据的LRU缓存的创建为什么这么慢。

(require '[clojure.core.cache.wrapped :as cw])
(time (cw/lu-cache-factory {} :threshold 10000000))

瓶颈似乎在这一行，lru列表被填充了虚拟值。我查看了LRUCache代码，没有看到阻止lru列表自然增长的任何理由，我还测试了带着更简单初始化函数的LRUCache

(defn- build-leastness-queue
  [base start-at]
  (into (clojure.data.priority-map/priority-map) (for [[k _] base] [k start-at])))

所有的LRUCache测试仍然通过。

原始的build-leastness-queue也被用于LUCache，而在使用新版本时，测试不再通过。在尝试让修改后的版本对LUCache也起作用时，我意识到目前它有点出错了。

(require '[clojure.core.cache :as c])
(def ca (c/lu-cache-factory {:a 1 :b 2} :threshold 2))
 
(-> ca
    (assoc :c 3)
    .lu)
;; => {:a 0, :c 1}

(-> ca
    (dissoc :a)
    (assoc :c 3)
   .lu)
;; => {:c 0, :b 0}

因此，根据当前的实施情况，新关联的（未命中）项目在LU缓存当前是否满的情况下地初始LU优先级可能有所不同。

今天早上我签署了Clojure CA，想知道是否有人能把我添加到JIRA，这样我就可以为这些问题提出补丁（那里的名字是FiVo）。

关于LUCache语义的一个额外问题。测试中包含注释确保测试结果不依赖于任意的基于命中次数的决斗者，但它似乎依赖于任意的决斗者。

(def ca (c/lu-cache-factory {:a 1} :threshold 2))

(-> ca
    (assoc :b 2)
    (assoc :c 3)
    (assoc :d 4))
 ;; => {:b 2, :d 4} 

后来的关联项目应该有更高的优先级吗？这将使补丁变得更加复杂，我强烈倾向于保持任意的决斗者。

Answer 1

我当然愿意接受补丁。我今天会看看如何给你提供Jira访问权限。

至于胜负决定者，我需要再次查看代码以重新加载上下文，但我怀疑那个注释是不必要的，应该被删除。