Closed josh-7t closed 2 years ago
@josh-7t Well, I've been playing around with it for the last hour, using Criterium for a second opinion (because Criterium factors in its own overhead), and the results are the same.
I'm not sure why the ConcurrentHashMap-backed version is 1000x slower, but my guess is it's related to the wrapping/unwrapping of the value in a delay, or maybe the bookkeeping overhead in ConcurrentHashMap. I was worried the delay was necessary for certain behavior, but it's unwrapped immediately. It replaced some older code that swapped nils in and out with ::nil because ConcurrentHashMa can't store nulls, so I don't think it's relevant.
I don't think it's worth investigating more deeply, so let's go with plain memoize
. Can you clean up? Let's remove the core.memoize and metrics-clojure deps, and move byte-streams-memo-benchmark
into a gist in case we ever need to revisit it.
Just checking in, I've made the requested changes. Is this good to go in?
Sorry, I moved to another country, and have been a bit distracted. Merging now.
Hey, no worries. That's a big thing! Thanks very much!
See https://github.com/clj-commons/byte-streams/pull/48 for the error encountered in graal.
According to the simple benchmarks that I came up with it looks like
memoize
andfast-memoize
are very close in performance.I also benchmarked the different options available in https://github.com/clojure/core.memoize in case one of the caching strategies there is useful.