Hacker News Reader

Comment by bitcracker | Hacker News Reader

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 server to serve the application as client which reduces the startup time but this is not very convenient to use.

The slowness of Clojure is a typical problem of all languages which are based on JVM. Racket Scheme, for instance, which is a Lisp like language but NOT based on JVM, needs just 0.062s to print "Hello World" (compiled) on my system.

View on HN

Did you read the article? The majority of the Clojure startup time is spent on initializing the Clojure runtime.

"spends 95% of the startup-time loading the clojure.core namespace (the clojure.lang.RT class in particular) and filling out all the metadata/docstrings etc for the methods. This process stresses the GC quite a bit, some 130k objects are allocated and 90k free-d during multiple invokes of the GC (3-6 times), the building up of meta data is one big source of this massive object churn."

> The majority of the Clojure startup time is spent on initializing the Clojure runtime.

That's correct but even without this startup time Clojure is significantly slower than other functional languages. Look at SBCL and Racket in

http://shootout.alioth.debian.org/u32/which-programming-lang...

That doesn't mean that I don't like Clojure. I am even considering it for a business project. But Clojure is definitely unsuitable for small apps (shell scripts etc.)

Btw the benchmark listing doesn't take LuaJIT into account. This JIT is the fastest I have ever encountered, way ahead of JVM regarding startup time.

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.

if you mean clojure AOT, it precompiles clojure to jvm bytecode. Usually the term JIT in this context is used to describe the native code generated by the VM on the flight, not the on the flight VM bytecode generation performed by a higher level language like clojure.

EDIT: sorry, probably your referred to http://publib.boulder.ibm.com/infocenter/java7sdk/v7r0/topic...

According to this link precompilation with AOT produces worse results than normal JIT execution. If so, what is AOT useful for?

"Da AOT-Code über verschiedene Programmausführungen hinweg bestehen bleiben muss, ist die Leistung von mit AOT generiertem Code nicht so gut wie die von mit JIT generiertem Code."

It helps with startup time. It's not that it produces worse code, it's that there's multiple levels of compilation. It stores the equivalent of -O1 on disk, and eventually some of the code can ramp up to -O3+. This is almost entirely to help startup time so that you don't have a bunch of code trying to compile during startup.

For dynamic languages such as Clojure or JRuby, a "JIT cache" would do no good.

Don't assume that an interactive language is necessarily interpreted. Clojure compiles to JVM bytecodes: http://clojure.org/compilation

Reply on news.ycombinator.com