Comments on Sven Efftinge's Blog: Groovy, Scala, Java, Xtend - a stupid comparison

Indeed, if you change "+=" to "<...

2012-01-04T16:59:28.181+01:00

Indeed, if you change "+=" to "<<" in the Groovy version you get 256ms, @8X better performance than the rigged, errr, supplied benchmark ;-)

Still, slower than the statically typed versions, but then again, Groovy's mandate to-date has not been to provide raw number crunching power. The right tool for the right job.

@all: Thanks for the feedback. I incorporated it a...

2011-12-21T10:48:28.737+01:00

@all: Thanks for the feedback. I incorporated it and wrote an update post : http://blog.efftinge.de/2011/12/groovy-scala-java-xtend-updated-stupid.html

Your Java version wouldn't compile for me: &qu...

2011-12-21T01:23:43.173+01:00

Your Java version wouldn't compile for me: "y" needs to be an Object, not a Comparable.

Also You could write the Java version 3 lines shorter if you use Arrays.asList(new Object[] { "foo", 23, true } as a poor man's List literal. Java isn't always as verbose as everybody is claiming ;-)

10000 iterations are probably not enough for a comparison: If I go from 10k to 100k iterations, the Scala version needs 5x time -- the Java version only 2x.

2011-12-21T01:07:25.667+01:00

This comment has been removed by the author.

Sven, you found an example in which Groovy cannot ...

2011-12-21T00:40:45.659+01:00

Sven, you found an example in which Groovy cannot do different than look bad. Groovy uses a fair amount of caching to get method invocations fast, but your code makes this caching not work at all. So your test there makes no argument about dynamic dispatch in general, just for a case, in which Java would look also very bad, if you would reproduce it there. The thing is only you cannot easily do that. In Java the method is preselected during compilation, the maximum you can get there is that you produce a scenario in which Java has to interpret.

As for the Groovy program, there are some things that you could use to make it faster, but there is a big conceptual difference between the Groovy program and the others. In the Java version you make a foo(Object) method and in there check by instanceof. That means you will get only one method. In Groovy those methods are all existing and there exists no dispatcher method.

Imagine a class with those three foo methods written in Java. Then in Groovy you can still run your test. I dare to say that in Xtend you cannot make this work without a dispatcher method somewhere - and your dispatch keyword is implying that - thus I assume you cannot make this then work using a Java class.

But let us not stop here... let us assume that you write the base class in Java, where it knows foo(String) foo(Object) and foo(Boolean). Using this class the Integer variant would call the foo(Object) method in your code. Now extend that class in Java with a foo(Integer) method and Groovy would no longer call foo(Object) but foo(Integer).

I doubt you can easily simulate that case.

Anyway.. coming back to your test. The call site caching in Groovy works by assuming that the parameter types do not change in most cases. In your case they change on each call, thus part of the performance problem.

In the Java case you are not testing method call performance at all, instead you test the performance of ArrayList#add. And the list operation dominates the Groovy program as well, since the Groovy program uses +=, which does create a new list each time. If you change it to <<, then it will also use ArrayList#add and performance should be somewhat factor 5 better. Then Groovy is still 10 times slower than the Java version of course. But at least not those 50x, and would you force Java in interpreted mode, it would have about the same slow down.

And in Clojure (without any mutable datastructure)...

2011-12-21T00:15:25.446+01:00

And in Clojure (without any mutable datastructure):

(defn foo [x]
(cond
(number? x) "Number"
(string? x) "String"
(= (class x) Boolean) "Boolean"))

(time (println (count
(map foo
(apply concat
(repeat 10000 ["foo" 23 true]))))))

Prints:
30000
"Elapsed time: 194.046477 msecs"

The Java version needs 31ms on my machine.

2011-12-21T00:00:30.530+01:00

This comment has been removed by the author.

Hey Sven, the Groovy code is too slow for the wo...

2011-12-20T22:11:20.827+01:00

Hey Sven,

the Groovy code is too slow for the work it should do. Please change the line
absoluteResult += foo(y)

into absoluteResult << foo(y)

The << operator is much faster. I am not sure if the += construct always create a new list with the old values + the new one.

Thorsten

Hi Sven. If you want maximum performance in Scala...

2011-12-20T21:45:43.183+01:00

Hi Sven.

If you want maximum performance in Scala you need while loops. For "loops" are "just" syntactic sugar for fold left and filter.

I rewrote your little program to use while loops and the java utils collections and the scala version was as fast as java - but nearly as ugly to :-D

Anyway - keep the great work with Xtend!