All I can say is that Java startup time is abysmal. Still, and after fifteen years. Java was dead slow in the 90's and it's dead slow these days when compared to anything else. I love Clojure but Java startup time rules it out for anything else but long-running processes or, when coding, using repl via swank.
If you want a quicker execution time for a short lived program, just tweak the settings. But then Java may not be the best choice for short lived 'scripting' anyway.
So yes, it rules it out, unless you know what you're doing.
More details: http://ericmiles.wordpress.com/2010/03/23/intro-to-maven-she...
Note that, startup time aside, Java's overall performance is actually quite good, due to the JIT compiler: http://stackoverflow.com/questions/145110/c-performance-vs-j...
Space overhead doesn't matter for most applications. But it makes Java a no-go for embedded devices and data-intensive domains.
A trivial hello-world in Java takes ~130 ms on my Debian sid box with « OpenJDK Runtime Environment (IcedTea6 1.8.7) (6b18-1.8.7-4) / OpenJDK 64-Bit Server VM (build 16.0-b13, mixed mode) ». This is with all default runtime options.
The program « (ns hello (:gen-class)) (defn -main [] (println "Hello, world!")) » compiled with Clojure 1.2.0 (again from Debian sid) takes ~1700 ms. Using -Xbootclasspath takes it down to ~800 ms. -client doesn't do anything obvious. Unpacking the Clojure JAR increases the time.
So presumably there's something about pulling in the Clojure runtime pieces that is very slow, but I have no idea what it is.
Why would this take so much time?
You feed the application's classes to the tool, which optimizes them for performance and saves the results to disk. Now, you can deploy your Java application in optimized form so that it runs fast from the start on target systems.
...
Using the Excelsior JET Optimizer, you convert the classes into highly optimized x86 code and create a native executable for Windows or Linux. This technique is called Ahead-Of-Time (AOT) compilation. "
However, as one of the later mails[1] says, "such a short program doesn't give the JIT time to warm up"—"Hello world" is a poor comparison to real-world performance.
http://lists.nongnu.org/archive/html/chicken-users/2011-03/m...
That depends on what you mean by "real-world performance". The board on which this conversation takes place compares Java to Python, bash and C. Their "real-world" probably consists of a bunch of short-lived small programs on the command line, lots of i/o pipelines etc etc. I think the benchmark gives a meaningful measure of "fit-for-purpose" for that kind of workload.
Do SSDs magically fix this?
Not that this benchmark is actually indicating anything about which language to use in any of those circumstances (Java has a bad startup but pretty good during runtime, and startup time on these orders is generally irrelevant for any nontrivial application), but that isn't to say that language benchmarks in general are irrelevant.
For some more info: http://harmful.cat-v.org/software/dynamic-linking/
EDIT: a micro-benchmark between static and dynamic C program:
gcc -- static a.c
time (for i in `seq 1024`; do ./a.out > /dev/null; done; )
real 0m0.958s
####
gcc a.c # that's dynamic linking
time (for i in `seq 1024`; do ./a.out > /dev/null; done; )
real 0m1.292s
The code:
#include <stdio.h>
int main(void) {
puts("hello world!");
return 0;
}What a misleading example. That's not GNU hello world, that's Linux hello world. The difference: it does not use GNU libc nor any other parts of GNU project -- except for the `unistd.h' -- but instead interfaces with the kernel directly.
Another matter is that it's not a C program, as it doesn't have int main(...) :P
[/nitpick mode]
Hm... huh?
So it looks like PHP is a good deal slower than python, and certainly perl. 22 times slower than C..
echo 'class Hello {public static void main(String[] args) {System.out.println("hello, world");}}' > Hello.java
gcj --main=Hello -o Hello Hello.java
time ./Hello
echo 'main() { printf("hello world\n");}' | gcc -x c -o hello -
time ./helloAgain, with the rapid unexplained downvotes... seriously, did you see the article about speeding up Eclipse? The suggestion was to make sure you're not using gcj and others commented that they agree'd. It's well known the gcj is just flat slow compared to Oracle's/OpenJDK.
lol, whatever guys, pile on, I must be missing the joke!
Eclipse is not representative of a typical command line program. Write "ls" with the OpenJDK and tell me you don't pull you hair out waiting for it to start up when using it.
But I can see how compiling a simple program with gcj could make it faster.
"Astonishing indeed. The whole thing confirmed my hunch that Bash, Chicken, and C provide a complete toolset to tackle 99.9% of programming needs."
No no no! Try running anything non-trival in bash or python and compare that to the java. Obviously if all you ever want to do with programming is write little boring scripts then you shouldn't be using a language like java in the first place. For anything mildly interesting and performance intensive Java is pretty much a no brainer only behind c/c++ amongst the major languages. For a site with REAL benchmarks which actually mean anything unlike the language fanboyism in this posted article checkout http://shootout.alioth.debian.org/u64q/which-programming-lan...
http://shootout.alioth.debian.org/gp4/benchmark.php?test=hel...
But "if all you ever want to do with programming is write little boring scripts" it might help to understand that 9 hundredths of a second delay is below the threshold that someone using the boring little script will notice.
And "if all you ever want to do with programming is write little boring scripts" simply using Java as an interpreter with -Xint might be faster.
For example, that old benchmarks game n=200 "hello world"
Java 6 -Xint 15.429s
Java 6 -client 16.929s
Java 6 -server 17.073s
Java 1.4 -server 35.738sThat does not seem to be the use case that's being examined.
The use case that's being examined is - "writing shell scripts / cron jobs / random commandline utilities".
When "writing shell scripts / cron jobs / random commandline utilities" I believe my priorities are
1) Does it work? 2) How easy is this to write? 3) How easy is this to read?
In that order.
http://lists.nongnu.org/archive/html/chicken-users/2011-03/m...
You can disable it using the -S option if/when you care about startup time.
Here are some numbers on my MacBook Pro:
$ ./run.sh bash hello.sh
median 0.002
$ ./run.sh python hello.py
median 0.016
$ ./run.sh python -S hello.py
median 0.008
Assuming the bash program was: `echo "hello, world!"`
Edit: I likely am mistaken. Chances are this was done using the builtin 'echo', not '/bin/echo'. The builtin is always faster (though putting them in a file (as is the only fair way to do it) slows them both down of course).
This article is basically trolling java, and it seems a number of people have taken the bait. Different languages have different strengths and weaknesses. You'll choose the one most appropriate to the task required. If that's printing "Hello World" to the console then fine, but I doubt many people would think "java" when presented with this requirement.
4 ms: C, gcc (median real time)
4 ms: bash
5 ms: LuaJIT 2.0.0-beta4
73 ms: Python2.6.1