views:

460

answers:

3

The Question actually says it all.

The reason behind this question is I am about to start a small side project and want to do it in Scala. I am learning scala for the past one month and now I am comfortable working with it. The scala compiler itself is pretty slow (unless you use fsc). So how well does it perform on JVM? I previously worked on groovy and I had seen sometimes over performed than java. My Question is how well scala perform on JVM compared to Java. I know scala has some very good features(FP, dynamic lang, statically typed...) but end of the day we need the performance...

+14  A: 

A majority of my work uses Scala as a high-performance language. If one really pays careful attention to performance, Scala is almost always nearly as good as Java (if not equivalent). If one is careless about e.g. object creations, it can be many times worse--as it can in Java if you use a library that is careless about object creations. (In fact, my Scala code is often faster than my Java code because I find it so much easier to make my highly optimized code convenient to use and reuse--but the Java would be as fast or faster if only I had more time and patience.)

If you want some data that demonstrates that Scala can be basically as fast as Java, check out the results on the Computer Languages Benchmark Game. (Another less useful but still interesting comparison for high-throughput multicore programming is Tim Bray's Wide Finder 2. This is less useful because the algorithm is not defined in advance, so a large portion of the differences boil down to differences in algorithm.)

Rex Kerr
Object creation in a modern Java JVM 1.5 > are practically free, this is just FUD. Scala is slower than native Java because of all the indirection for all the Scala specific language features just like Groovy. You should expect as much as a 5X speed penalty compared to Java on the same JVM.
fuzzy lollipop
@Fuzzy: You are just plain wrong. Go look at the benchmarks I linked to. Do they support your position? Care to post others that do? Have you done microbenchmarking to tell how fast object creation is compared to one layer of indirection--and how well the JIT can remove indirection when it's not truly needed? (Hint: I have, and that's why I posted what I did.)
Rex Kerr
@fuzzy I'm endorsing Rex here. Object creation is cheap, but if all you are doing is a handful of math operations in the inner loop, then, by comparison, object creation is highly expensive.
Daniel
scala uses native 'int', 'float', or whatever (not Integer, Float, etc.) if all you are doing is match in an inner loop. there would be little difference to native java, if any.
LES2
@fuzzy: object *allocation* is cheap. Object *initialisation* can be arbitrarily expensive; even just shallow copy constructors can wind up taking significant time if you create enough objects. You know, the kind of copy constructor you call all the time in functional code, because you're using immutable objects instead of mutable state ...
Porculus
+2  A: 

Scala is compiled down to byte code and is statically typed so many of the same optimizations that can be done for statically typed languages like Java (as opposed to dynamically typed languages like Groovy) can be done. So comparing Groovy to Scala is comparing apples to oranges.

Now, Java to Scala comparison:

You can expect Scala to be on par with Java in most situations. Scala can be slow if you program in it stupidly, e.g., tones of mix-ins via Traits could provide some overhead that plain Java wouldn't have.

But ...

If the Traits are actually solving a complex problem in good taste, then a solution in plain Java would have to tackle that same complexity. Who's to say the solution you write in Java using your own patterns is going to be more efficient than what you get for free in Scala (remember, the Scala compiler was written by people that are probably a better programmer than you are).

On the other hand, if you are using language features for no good reason (e.g., Integer objects when plain int primitives will do), your code will be bloated, slow, crap no matter which language you use.

In addition, consider the special class of request-response based applications that interact with a database or other I/O intensive resource. The bottle neck is not going to be the 'new' operator or virtual method invocation overhead - it will almost certainly be the I/O.

In summary, performance between Scala and Java is about the same, and shouldn't be the biggest reason you choose one over the other in 99% of cases. Since skilled human labor is more expensive than computer hardware, you are better off choosing the language that you can (or can learn to) program most efficiently in (including your teammates). If Scala lets you write one tenth the code as Java, you might gain 10X the benefit by using it. If Scala slows you down 10 times (because it's too hard to read), stick with Java!

LES2
This is all true in theory. In practice, if you measure things instead of just expecting things, Scala code tends to be significantly slower than Java code, just as in practice Java code tends to be slower than C++ code.The "don't worry about speed, throw hardware at slow code" argument is less true every day. On the client side, netbooks and mobile phones are NOT fast. Server-side, there's pressure to reduce energy usage. We're not going to go back to hand-tuned ASM, but it's worth thinking carefully what Scala buys you.
Porculus
Actually, I'm yet to be able encounter any measurable speedup by porting any program from Scala to Java alone.
Seun Osewa
+1  A: 

I agree with Rex's comments in this post, and I have personal experience to support it. I converted a Processing applet from java to scala, without changing any implementation details, and both applets rendered a frame in ~6ms, with little variation.

nullspace