How well does Scala perform compared to Java? [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. 开发者_如何学JAVA Closed 10 years ago.

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...

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.)

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!

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.