In regards to the allocation objection--how often are you calling seq millions of times on something that's not already a seq? In re using count instead of seq, a lazy seq's count might be arbitrarily expensive to calculate and might not be able to tell if it's empty without realizing its head.
On Monday, May 13, 2013 4:21:54 AM UTC-5, Meikel Brandmeyer (kotarak) wrote: > > > 2013/5/13 Mike Thvedt <cynic...@gmail.com <javascript:>> > >> A good implementation of ISeq won't return a new object, and new >> short-lived objects are cheap on the JVM anyway. OTOH count can be slow for >> some data structures. if you don't like instantiating lots of new objects >> only to throw them away, you're missing out on one of HotSpot's most >> significant performance/convenience sweet spots, so it's strange you call >> that premature optimization. >> >> There is however an optimization story against seq: Hotspot (at least on >> my machine) refuses to inline the call to seq by default (it might still >> inline if the stars are right or something, the JVM is mysterious). My >> guess is it's because the code in seq and seqFrom is too big, on my box it >> exceeds the inline threshold by one byte... >> >> > I'm not sure what you mean. For an ISeq seq won't return a new object. > But for everything else it will. And count is cheap (a simple field > access) for clojure data structures (a seq is not a data structure). While > initialising an immediately-to-be-thrown-away object might be (relatively) > expensive even when allocation is cheap. > > I called my point of view "premature optimisation" because it's probably > like you said: allocation is cheap and initialisation usually not worth > worrying about. So worrying about it is "premature optimisation". > > I still feel empty? to be too ugly in its current implementation. (And to > be honest: I almost never needed it, up to now...) > > Meikel > > -- -- 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 Note that posts from new members are moderated - please be patient with your first post. 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.