Hacker News Reader

Comment by SeanLuke | Hacker News Reader

>> I work a lot with Rhino, JRuby, Jython, Groovy and Quercus (a JVM PHP engine), and can anecdotally say that Clojure and Quercus are "fastest" of their breed for the kind of web development work I do.

Interesting. We maintain a Java-based simulation toolkit in which the target language (Clojure, whatnot) must make a lot of calls to Java and work with a lot of mutable Java data. And it's been our experience that Clojure is -- I do not make up this number -- approximately 1000 times slower than Kawa for such tasks. Mostly because of immutability guarantees and Refs. Indeed, it's one of the slowest languages on the block for this task.

I wonder how Kawa would perform in his web development arena. I've found it the fastest non-Java JVM language anywhere.

View on HN

In my experience (using Clojure full time since before there were official releases), Clojure can be written exactly as fast as java. That isn't idiomatic clojure code however.

The features clojure provides are somewhat slower, but well worth it. The purely functional datastructures are ~25% slower than their java equivalents. The seq abstraction is slightly slower, but allows handling infinite sequences, and only passes over the data once.

About the only thing I'm aware of that can slow your code down that much is by using reflection in a tight loop.

Hop on to #clojure on irc.freenode.net, we'd love to help you out.

I'm actually not able to follow your usage scenario. Do you mind providing a representational bit of code to illustrate?

Your claim does not line up with reality. http://shootout.alioth.debian.org/u32/which-programming-lang...

http://blog.dhananjaynene.com/2011/08/cperformance-compariso...

Those Clojure benchmarks in the above post were submitted by me to show that you can get Java/Scala performance.

EDIT: Toned down the rhetoric

I think it is interesting you point the parent out for not lining up with reality. Can you elaborate on how the benchmarks in the above posts are a more realistic way to reason about the performance than the experience of the language used in a real life project?

These exact same techniques used in these benchmarks are used in "real life" projects, for example this one that I work on: https://github.com/clojure/core.logic

This is a Prolog-like engine that I benchmark against SWI-Prolog (written in C). It comes close on some benchmarks, and surprisingly surpasses on a few.

Fair enough, however I don't see a benchmark which measures the performance of Clojure in a situation described as above (dealing with a lot of mutable java objects) compared to other (JVM) languages. He clearly mentioned, for such tasks, clojure is 1000 times slower than Kawa. The fact that Clojure is fast for other types of programming problems is irrelevant for this particular case.

If the poster had could give a (minimal) example to demonstrate their claims, then we could know for sure. Otherwise, we have no idea what the problem was.

are you making many small calls, each of which modifies a small part of a large structure, and clojure is creating a new instance of the large structure each time? that sounds like a pathological case for idiomatic clojure, but i would have thought you could work round it by keeping the data in a more "java like" format without too much pain.

i've been using clojure for numerical processing this last few weeks and have been impressed how well it mixes lazy sequences and vectors. but i haven't had to face a case like you seem to be having.

Reply on news.ycombinator.com