ClojureScript performance revisited(numergent.com) |
ClojureScript performance revisited(numergent.com) |
You want immutability - think about it: how large % of your bugs are due to more than one procedure changing the value of one variable, and state getting out of sync?
For me in my JS day job, it is definitely a majority of the bugs we create. We also code very defensively to protect us against this.
In CLJS on the other hand, you'd have immutable data, and in tight loops where allocating objects would be expensive, you make your data transient, and then mutate it as much as you wish.
Living your life with immutable values is a serious improvement. Not only to code, but honestly quality of life.
Edit: Clojure doesn't return whole new data structures under the hood, but you never notice that. Here is a great explanation, prepare for (= (mind article) :blown) => http://hypirion.com/musings/understanding-persistent-vector-...
E.g., if your mutable code has to make many array copies, you've negated any performance advantage waiting for memory. Another great one is checking for differences in tree structures; you can replace deep equality checking with higher-up pointer comparisons, which is why Clojurescript fits so well with virtual DOM techniques like React.
(map
(defn f [c]
{:overlap-amount (circle-overlap-distance circle c)
:mid-point (mid-point circle c)})
circle-list)
Is there a reason this uses defn instead of fn? This is the first time I've seen defn used like this.Since this expands to something like (def f (fn [c] ... and f is never used anywhere, I'd change it to fn. If f is used, I'd consider letfn instead.
The revised code replaces it with #(...) which is shorthand for (fn [...] ...), but am curious if there was a reason for using defn or if it was just an oversight.
I believe it was an independent function initially that I just plunked in there right before setting the gist live, since I wasn't using it anywhere else, but that was back in January.
Not sure what you mean.
While the framerate for the ClojureScript version was mistakenly capped at 30fps, if you look at the original numbers they had never hit that, which is why I hadn't noticed. A 30fps throttle is hardly your problem if you are hitting 5fps.
Even after upgrading ClojureScript to 1.7.170 there's only one result that could potentially have been affected - the one for 100 agents. Given all others were under 30fps, they wouldn't have been affected by the accidental throttling before the tweaks.
Cheers!