Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is Clojure so slow?

martinsprogrammingblog.blogspot.de

Post reply on HN
Print view View original

51–60 of 97 posts

Re: Why is Clojure so slow?

#51

Post by fauigerzigerk »

rbanffy wrote: post #9

How slow is slow? If it takes me 3 months to deliver a given program in Clojure and 6 to deliver its Java equivalent, the Clojure one already has 3 months of lead. Assuming the Java one is twice as fast, it'll take 45 days to catch up. Development time is expensive, computers are cheap and get twice as fast every year or so. While a long startup time is annoying, it can certainly be optimized out if someone focuses e…

That 45 day head start must be divided by the number of users running the program though.

Re: Why is Clojure so slow?

#52

Post by Chrix »

The Clojure's start-up is slow because the source files are compiled. But once your program is launched, its perfs are correct and very close to Java. About the immutable data structure, don't forget each method doesn't return a copy of the data. It's more clever using changes detection.

You can read a lot of information about this part of Clojure in the book "Practical Clojure". I'm reading it and I'm learning some stuffs about Clojure.

To conclude, Clojure is fine for "long" program running.

Re: Why is Clojure so slow?

#53

Post by thebluesky »

theatrus2 wrote: post #5
ivanb wrote: post #4

If Clojure could dump the Lisp image like SBCL's save-lisp-and-die function, the startup time would be greatly reduced. I wonder if JVM itself can dump its current state and then restore execution. Another approach to the problem would be similar to FastCGI: keep one Clojure server process running and execute scripts on it.

Sadly the JVM can't really do that (yet?). Even for normal Java applications caching the JIT would really help ramp-up time in servers.

It doesn't really buy you much since it's slower to read from disk than for the JIT to generate code on the fly.

Re: Why is Clojure so slow?

#54

Post by zenogais »

kayoone wrote: post #23
rbanffy wrote: post #9

How slow is slow? If it takes me 3 months to deliver a given program in Clojure and 6 to deliver its Java equivalent, the Clojure one already has 3 months of lead. Assuming the Java one is twice as fast, it'll take 45 days to catch up. Development time is expensive, computers are cheap and get twice as fast every year or so. While a long startup time is annoying, it can certainly be optimized out if someone focuses e…

Development time != execution time

That was the point. Execution time is mostly inconsequential when compared to things like development time and competitive edge provided by the language you're using - you know, the actual money makings factors.

Re: Why is Clojure so slow?

#55

Post by seanmcdirmid »

Chrix wrote: post #52

The Clojure's start-up is slow because the source files are compiled. But once your program is launched, its perfs are correct and very close to Java. About the immutable data structure, don't forget each method doesn't return a copy of the data. It's more clever using changes detection. You can read a lot of information about this part of Clojure in the book "Practical Clojure". I'm reading it and I'm learning some…

As others have stated, the OP was comparing run time separately from startup time, closure was found only to be about 4 times slower than java after startup costs are a storied away, which is quite believable given the benchmarks.

For most programs that aren't compute intensive, you won't notice a penalty, but the same is true with ruby or python.

Re: Why is Clojure so slow?

#56

Post by kibwen »

fogus wrote: post #47
kibwen wrote: post #35

Earlier quoted context omitted.

I wonder if his figure is simply mistaken, then. Because 100 kilobytes is a heck of a lot of code for a hello world. The compiled representations in your blog post seem far more reasonable.

100K is a lot of code for a Hello World, so don't use ClojureScript to write Hello World apps. The cool part is that building a largish app will not necessarily grow the output JS.

Sure thing, but my curiosity still stands. :) If you're using Closure Compiler to perform dead code elimination (100kb is the "heavily optimized" number, as far as I can tell), how is it that `console.log('hello, world!');` requires 100kb of essential (non-eliminatable) scaffolding?

Re: Why is Clojure so slow?

#57

Post by martintrojer »

Have a look at Rich Hickey's keynote presentation from Conj2011; http://blip.tv/clojure/rich-hickey-keynote-5970064

He pretty much starts off by talking about making Clojure "leaner", faster at starting up etc.

He mentions stuff like a "production" jar with less metadata, hoisted evaluator and even some kind of tree shaking ala ProGuard.

Re: Why is Clojure so slow?

#58

Post by CountHackulus »

bitcracker wrote: post #40

It's an implementation problem of Java. I never understood why the JVM folks didn't get along to develop a JIT cache. That means the first time I start a Java program it would run normally slow. But from the second run on it would use the native cache and run immediately fast with native performance. That would eliminate many performance problems of Java. I know that there already is a solution which uses a Java serv…

That "JIT cache" you're talking about already exists. It's known as AOT, or "Ahead of Time" compilation. I forget how you enable it, but it's there.

Re: Why is Clojure so slow?

#59

Post by [deleted] »

Mitt wrote: post #28
rabidsnail wrote: post #10

Earlier quoted context omitted.

Vars already default static, so we just need to take better advantage of that in the compiler.

Yes, Clojure 1.4 defaults to static. However, a Var still needs to do an extra lookup at runtime. A Var does not directly point to the object that I want. And Vars have to be that way, this is their core feature. Clojure is a dynamic language, so they need to stay dynamic too. All code constantly assumes that the objects behind Vars will change. Let’s say we have `(defn foo [] 1)`. The caller of (foo) will first look…

[deleted]
Post reply on HN