On Sun, Feb 24, 2013 at 5:50 AM, bernardH <un.compte.pour.tes...@gmail.com>wrote:
> FWIW, I, for one, am really glad that Clojure allows us to select > precisely which nice tools we want (have to) throw away (persistent data > structures, dynamic typing, synchronized) when the need arises. Reminds me > of the "don't pay for what you don't use" motto of C++ except done right > (i.e. the other way around, because you don't want to pay wrt simplicity > rather than performance, cf. "premature optimization…") > I think this notion that Clojure lets you select exactly what performance tools you want to pay for when the need arises overlooks one important point -- in Clojure it is not obvious what tools you need to employ to solve a given performance problem. As I mentioned before, I'm generally happy with Clojure's performance, but the few times I've had performance problems, I ended up rewriting the code at least three different ways in order to try to find the magic combination that would boost performance. Similarly, every snippet of well-tuned optimized code posted on this list has generally been iteratively tuned by several performance experts, often through a process of educated guesswork and trial and error. On two of my own performance-bottleneck occasions, I went through a major rewrite to use defrecords rather than hash maps, only to find that it *hurt* my performance. If a reasonably expert Clojure programmer can't make good predictions about whether a given rewrite will help or hurt performance, that's something that must be taken account in any discussion about how well Clojure lends itself to optimization. I also think it's not entirely true that Clojure lets you easily choose "what nice features you want to throw away" in pursuit of performance. In one algorithm involving massive pointer manipulation in a tight loop, even after much experimentation, I was never able to figure out how to jettison enough of Clojure's mutation straitjackets to get anywhere close to Java performance. I had no choice but to drop down to Java for that algorithm. Fortunately, dropping down to Java is relatively painless. But I still wonder whether there might be some benefit to having a "low-level DSL" within Clojure, a mode that lets you choose to write your code in a way where the semantics are closer to the underlying platform. I haven't used Clojurescript much, but I get the impression that Clojurescript is already a step in that direction, with a simpler story regarding how mutation, arrays, and primitives are translated to the underlying platform, arguably making it easier to get good performance when you need it. -- -- 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.
