Clojure Performance Tips – WTF?

When I read about the clojure performance tips, I was quite amused. Well, the first two tips are OK. Clojure tries to be dynamic, and I cannot think of a dynamic language living in the JVM not using reflection in some cases. So type hints can be a good thing to optimize. Not using Wrapper-Classes but using primitive types also seems like something plausible – tell the Compiler that your number stays small enough so it can optimize.

But then… Use binary arithmetic operators. WTF? It is slower to say (+ 2 3 4) than to say (+ 2 (+ 3 4))? Because „For a while now, Clojure has supported inlining of certain expressions. For arithmetic operations, only the calls with exactly two arguments will be inlined.“ In his example, I thought, maybe passing the thing directly to the REPL makes it slower because it doesnt compile the expression. So I defined functions doing the same:

Clojure 1.0.0-
user=> (def hallo (fn [] (dotimes [_ 1e7] (+ 2 4 5))))
user=> (def hallo2 (fn [] (dotimes [_ 1e7] (+ 2 (+ 4 5)))))
user=> (time (hallo))
"Elapsed time: 5008.579881 msecs"
user=> (time (hallo2))
"Elapsed time: 1650.281717 msecs"

So actually, it seems true – sorry, to me this just shows that that compiler isnt really sufficiently intelligent for being a lisp-compiler – remember: lisp programmers know the value of everything and the cost of nothing (Alan Perlis). The other thing is that these functions are constant – they do not depend on any arguments or side-effects. Even a C-Compiler would just have replaced our definitions with something that just always returns the same value, nil in our case. And at least an arithmetic expression should be replaced if its constant (if not the whole loop).

Then … why the fuck is destructing binding slower than accessing a vector directly? Running the example from the above link gives other times (my computer may be slower), but the same outcome:

user=> (let [v [1 2 3]]
         (dotimes [_ 1e7]
           (let [[a b c] v]
             a b c))))

"Elapsed time: 2438.966297 msecs"
user=> user=> (let [v [1 2 3]]
         (dotimes [_ 1e7]
           (let [a (v 0)
                 b (v 1)
                 c (v 2)]
             a b c))))

"Elapsed time: 1649.46514 msecs"

Actually, I do not understand why both codes are not doing exactly the same? The first one should – imho – only be short for the second one, shouldnt it? And wtf? Making code less readable for performance issues? I thought this wants to be a lisp! In lisp you fit the language to your problem, not your problem to the language!

Anyway, its version 1.0 now – I hope they will optimize it soon. Before it becomes 2.0. I dont like clojure (for other reasons), its a step into a direction I dont really like, but at least it is a new step.


I am surprized that this post became that popular, and actually, this makes me a little sad, because I have already written more interesting stuff (at least as far as I think) noone cared about.

It is criticism about a few misfeatures in the language, which I think are major issues and should be corrected as soon as possible, but dont make clojure worse. I dont like clojure much, I have reasons for it (already posted a few of them – and no, the JVM is not a reason), but as I said, it is a step into a direction I dont like, but at least it is a step – and Lisp needs new steps.

And of course, this post is meant to be provocative (in an ironical way – I thought that was clear), so the fact that it raised discussions shows that it served its purpose.


6 Responses to Clojure Performance Tips – WTF?

  1. // popular today…

    story has entered the popular today section on…

  2. harbl sagt:

    wait, so you are upset because the performance tips contained accurate information?

  3. dasuxullebt sagt:

    I am not upset, I am amused. I thought that was clear. These points dont really make clojure worse, and I am sure they will fix them soon or later. Actually, I dont understand why the clojure-community is so angry about this post (as seen on reddit). Well, I will edit my post to make that more clear.

  4. harbl sagt:

    Fair enough, I misread your tone. It is sort of amusing. I read the performance tips more as „Here are things that do not work very well yet, and some modifications you can make to your code to avoid problems if you need a solution right now“. I respect them for providing that resource, as opposed to other languages which try to hide where their weak spots are.

  5. sys sagt:

    Hi, what are your other reasons for not liking Clojure?
    I use it when I have to work with a JVM, and it beats all other JVM languages out of the water.

  6. dasuxullebt sagt:

    When working with a JVM it may be a good choice (I am sure these performance problems will go away soon or later). To me it simply doesnt „feel good“. A few complains are written here: (but this post is rather old). Mainly, its personal preference, rather than an objective argument (thats why I didnt discuss it deeper here).

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

Du kommentierst mit Deinem Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )


Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )


Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )


Verbinde mit %s

%d Bloggern gefällt das: