This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-03-20
Channels
- # announcements (5)
- # aws (15)
- # babashka (12)
- # beginners (87)
- # calva (13)
- # cider (16)
- # clj-kondo (4)
- # clojure (22)
- # clojure-argentina (1)
- # clojure-europe (9)
- # clojure-houston (1)
- # clojure-nl (2)
- # clojure-norway (25)
- # clojure-uk (5)
- # clojurescript (12)
- # core-typed (37)
- # cursive (15)
- # datomic (40)
- # editors (8)
- # emacs (4)
- # events (1)
- # hyperfiddle (29)
- # keechma (8)
- # leiningen (6)
- # lsp (7)
- # malli (25)
- # off-topic (26)
- # pathom (10)
- # portal (3)
- # re-frame (22)
- # reitit (1)
- # releases (1)
- # ring (2)
- # shadow-cljs (18)
- # yamlscript (1)
Hey š I'm in need for a high performance LRU cache solution and looking at https://github.com/burbma/cljs-cache/tree/master wondering if I should be using that. My question is if the immutability (creating a new cache every hit/miss) + using an atom (which seems like the default way) is slower than creating some dynamic variable which I can just change in place. Will it even gain performance improvements? Are there risks which I don't know about for the dynamic variable solution?
maybe a silly question... but have you already benchmarked it and established cljs-cache is not fast enough/bottleneck?
Not a silly question at all š Two things : 1. I'm not sure how can I bench mark such a thing. I understand that benchmarking it in the REPL/tests is not a good way because when running prod environment things tend to be very different. 2. I preemptively tried to predict if it can be a bottleneck (with knowledge other people have) so I won't waste time on it.
1. yes, I guess this is the case... 2. fair enough... and the only way of knowing for sure is actually measuring it. š¤· so you might need to prototype it. (and then find out it was not needed after all)
I think maybe there's some misunderstanding about "creating a new cache" here? The link below explains why that still performs well. Yes, you might be able to get something faster mutating in place. And how much faster might depend on how often evictions happen? IDK, but Riemann uses core.cache and is pretty darn fast. https://hypirion.com/musings/understanding-persistent-vector-pt-1
Hi ! Seems this interop is little bit challenging, right?
size({
apply({rects, elements}) {
Object.assign(elements.floating.style, {
width: `${rects.reference.width}px`,
});
},
});
Any idea how to access this desctrured apply
fn in size params please?Not sure what you mean by "destructured apply
".
What's being done is:
(size #js {:apply (fn [^js x]
(let [rects (.-rects x)
elements (.-elements x)]
(js/Object.assign (-> elements .-floating .-style)
#js {:width (str (-> rects .-reference .-width) "px")})))})
And if size
is a function where you need to access that :apply
function:
(defn size [^js x]
(let [apply (.-apply x)]
...))
As I like using applied-science/js-interop
lib for interop, here the final result that I use:
(size #js {:apply (j/fn [^:js {:keys [rects elements]}]
(j/assoc-in! elements
[:floating :style :width]
(str (.. rects -reference -width) "px")))})]}))
Thank again!