Say you're writing a function that is calling requestAnimationFrame in a recursive loop and you want to store an internal reference to the last requestId so it can be canceled by returning a dispose function. Consumers would never see or access the internal reference. Should I still use an atom or is there a lighterweight option I could leverage for that?
It's hard to even imagine a scenario where choosing a different alternative would be noticeable.
Having said that, you could store it in one of a number of different mutable places like a normal js variable, a volatile!, as an object member, or in an Array.
Thanks! Was thinking a js object + member as well
It might not be a huge difference but with requestAnimationFrame it can be more noticeable
With an animation frame, you have 1000/(monitor Hz) milliseconds.
16+ ms for 60 Hz, 8+ ms for 120 Hz.
That's an immense amount of time, relatively speaking. You will not notice any difference between various kinds of mutable state, unless you have thousands upon thousands of requestAnimationFrame started within the same frame, all with some mutable state.
Ah, my mistake! I am glad this community has experts like you two to guide fools like myself
I do not believe in "fast enough" mentality. volatile! is better than atom for your case, in the context of CLJS and no threads of course.
And a JS object is much better still. :)
not really, volatile! is basically a JS object
Ah, perhaps "much" is during dev only. But the code is still different in release.
I mean we are getting into territory where things get really hard to measure and JIT probably being smart enough to do the best thing anyway
FWIW my nitpick is more due atom for some reason having weird swap!/reset! implementations and an extra (instance? Atom x) check that is done every single damn time these are invoked. One day I'll get around to figuring out why and maybe fix it. but thats why atom has a certain smell I don't like 😛. I think its this way only because of historic reasons of being adding before protocols, but could be other things.
Yeah, I see your point.
Thanks! I always wanted an excuse to learn the volatile! apis