And benchmarks with rigor, I might add. Noting important dependencies that match chipset, bare metal CPU architecture/bus wiring and compiler choices.

In particular, I've spoken with people who have cited significant differences in performance, when using proprietary compilers matched to vendor CPU chipsets, for Linux/OpenJDK compilation, which then changes the profiling of the JVM benchmark, on the same bare metal crate.

Meanwhile, L2 cache misses, due to object reference churn, are the final deal breaker with the JVM, if I've read correctly and read enough about JVM performance. Beyond even garbage collection overhead, fundamental JVM performance cannot be tuned to optimize CPU cache use.

Briefly paraphrased, the JVM performs messaging/referencing with String references, that look like "java.lang.Object@%HASH_CODE%" and when you instantiate and garbage collect many instances (millions of those hellishly long fully qualified java names) across many operations, costing many cycles, you'll always suffer incurred latency, because most of your objects are frequently populated and then evicted from the L2 cache, no matter how long they actually live in the JVM heap.

I don't have the link handy, or I'd post it.

But long story short, even though a JVM benchmark may be performant, benchmarks do not peg CPU resources according to real life use cases.

And changing the OS, motherboard, and compiling from source on your own physical hardware can provide benefits that might not be obviously worth the extra effort to compile from source bootstrapping all the way from the kernel to the JVM, before deploying your java artifacts.

That a fair request, but the article doesn't say Clojure is faster than any other language, it just says it is fast. That caught my attention as well, because I don't think of it as being particularly fast (mostly due to startup time).

> because I don't think of it as being particularly fast (mostly due to startup time).

Proposal: Fast for server use-cases?

Curiously, I was never really interested in the startup time of most of my code, probably because most of my code is long running where it doesn't matter if it takes a few seconds more to start.

There are a few efforts out there to provide something with near instant start up time. Can be useful for scripting, for example.

Planck, which runs on JavaScriptCore: http://planck-repl.org/

Lumo, which runs on V8: https://github.com/anmonteiro/lumo

I was not interested in that either until I had to start Java processes by hand. The initial version ran for 5 minutes. I then refactored the app to be a long running service instead of a fire-and-forget app and the run time changed from 300 seconds to 300 microseconds!

Five minutes? Ouch .. when I think of "slow" start of Java processes it is more in the range of 5 to 10 seconds. Maybe a minute tops for an application server, but five minutes sounds ugly. Especially when it is all just start time.

Startup of a single JVM was around 10secs but I had to start up a JVM for each operation (think of it like a JUnit test suite from the command line). If you have several of these processes the whole thing is no longer O(1) but O(n) and you begin to see the JVM startup overhead.

Probably being compared to languages like Python, Ruby, and Perl. It should be pretty close to statically typed languages on the JVM like Scala. I think a real REPL is worth a little bit of performance.

FYI http://jpad.io/ REPL for java

Which are mostly worthless, because most keep mixing implementations with languages.