Laurent PETIT a écrit : > If I'm damn sure that the value will be set once from within the same > thread (here we are in the SWT UI Thread), is there a reason to prefer > atoms ? > (This is a real question, not a disguised affirmation that I'm doing > the right thing, so please arguments welcome)
Well I would pick atoms because I would ask myself the question the other way round "is there any reason not to prefer atoms?" and since the only reason I can think of is performance... You didn't choose to use an array because of its concurrency model but because its lack of and that's why, to me, it's a lower-level solution with which it's not worth to bother about unless you are forced to (by performance or interop). I understand that in this use-case you don't need concurrency but it doesn't appear to me as a sufficient reason to rule out a solution just because it happens to have a concurrency model — using an array didn't make the code simpler. I'm not sure I'm doing the right thing either, I'm just trying and explain how I came to the opposite conclusion. It's a sort of "Is the glass half empty or half full?" discussion. Christophe NB: microbenchmarking is hard: on my old laptop arrays are faster only for smaller numbers of iterations. Let's call it a draw :-) > > And concerning performance aset versus swap!, well, it seems that it > can vary from test to test. > The same test as yours but with 10 times more iterations : > " > Clojure > user=> (let [times 100000000] > (time (let [a (make-array Object 1)] (dotimes [i times] (aset a 0 2)))) > (time (let [a (atom 0)] (dotimes [i times] (swap! a inc))))) > > "Elapsed time: 4322.175633 msecs" > "Elapsed time: 10716.352073 msecs" > nil > user=> > " > > Here it's aset that wins over swap!. > > But really, it was not an ahead of time potential performance > consideration that made me use arrays. > It was more some sort of "XP" YAGNI thing. > > Now if there are valid arguments (concurrency issue I haven't > considered, code maintenance, proven really bad performance, etc.) for > using atom in this particular case, then I'll change my mind (and the > code:-). > > > -- > Laurent > > 2009/2/20 Christophe Grand <christo...@cgrand.net > <mailto:christo...@cgrand.net>> > > > Laurent PETIT a écrit : > > I haven't tried with something simpler that the array-like method, I > > suspect it won't work in clojure, too. And I didn't want to use > > clojure's mutable methods because : > > - we already are in an IO operation, the mutation is local to the > > operation > > - I don't want agents, because I don't want asynchronous behaviour > > - I don't want refs, because I don't have to coordinate access on > > several places by several threads > > - I don't want atoms, because I also don't have to serialize > access to > > a single place by several threads > > > > Hello Laurent, > > Not going with atom sounds like a premature optimization to me. Is the > overhead of using atom that important compared to what is executed in > the body of sync-exec? > In tight loops, the JVM seems to optimize away this overhead: > > user=> (time (let [a (make-array Object 1)] (dotimes [i 10000000] > (aset > a 0 2)))) > "Elapsed time: 1323.697565 msecs" > nil > user=> (time (let [a (atom 0)] (dotimes [i 10000000] (swap! a inc)))) > "Elapsed time: 991.807898 msecs" > nil > > Christophe > > -- > Professional: http://cgrand.net/ (fr) > On Clojure: http://clj-me.blogspot.com/ (en) > > > > > > > > > -- Professional: http://cgrand.net/ (fr) On Clojure: http://clj-me.blogspot.com/ (en) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
