16

I just started learning Scala, and I'm having the time of my life. Today I also just heard about Scala for Android, and I'm totally hooked.

However, considering that Scala is kind of like a superset of Java in that it is Java++ (I mean Java with more stuff included) I am wondering exactly how the Scala code would work in Android?

Also, would the performance of an Android application be impacted if written with Scala? That is, if there's any extra work needed to interpret Scala code.

Cœur
  • 37,241
  • 25
  • 195
  • 267
SamAko
  • 3,485
  • 7
  • 41
  • 77

4 Answers4

41

To explain a little bit @Aneesh answer -- Yes, there is no extra work to interpret Scala bytecode, because it is exactly the same bits and pieces as Java bytecode.

Enter image description here

Note that there is also a Java bytecode => Dalvik bytecode step when you run code in Android.

But using the same bricks one can build a bikeshed and the other guy can build a townhall. For example, due to the fact that language encourages immutability Scala generates a lot of short living objects. For mature JVMs like HotSpot it is not a big deal for about a decade. But for Dalvik it is a problem (prior to recent versions object pooling and tight reuse of already created objects was one of the most common performance tips even for Java).

Next, writing val isn't the same as writing final Foo bar = .... Internally, this code is represented as a field + getter (unless you prefix val with private [this] which will be translated to the usual final field). var is translated into field + getter + setter. Why is it important?

Old versions of Android (prior to 2.2) had no JIT at all, so this turns out to about 3x-7x penalty compared to the direct field access. And finally, while Google instructs you to avoid inner classes and prefer packages instead, Scala will create a lot of inner classes even if you don't write so. Consider this code:

object Foo extends App {
    List(1,2,3,4)
      .map(x => x * 2)
      .filter(x => x % 3 == 0)
      .foreach(print)
}

How many inner classes will be created? You could say none, but if you run scalac you will see:

Foo$$anonfun$1.class       // Map
Foo$$anonfun$2.class       // Filter
Foo$$anonfun$3.class       // Foreach
Foo$.class                 // Companion object class, because you've used `object`
Foo$delayedInit$body.class // Delayed init functionality that is used by App trait
Foo.class                  // Actual class

So there will be some penalty, especially if you write idiomatic Scala code with a lot of immutability and syntax sugar. The thing is that it highly depends on your deployment (do you target newer devices?) and actual code patterns (you always can go back to Java or at least write less idiomatic code in performance critical spots) and some of the problems mentioned there will be addressed by language itself (the last one) in the next versions.

Original picture source was Wikipedia.

See also Stack Overflow question Is using Scala on Android worth it? Is there a lot of overhead? Problems? for possible problems that you may encounter during development.

Community
  • 1
  • 1
om-nom-nom
  • 62,329
  • 13
  • 183
  • 228
5

I've found this paper showing some benchmarks beetween the two languages:

http://cse.aalto.fi/en/midcom-serveattachmentguid-1e3619151995344619111e3935b577b50548b758b75/denti_ngmast.pdf

I've not read the entire article but in the end seems they will give a point to Java:

In conclusion, we feel that Scala will not play a major role in the mobile application development in the future, due to the importance of keeping a low energy consumption on the device. The strong point of the Scala language is the way its components scale, which is not of major importance in mobile devices where applications tend to not scale at all and stay small.

Credits to Mattia Denti and Jukka K. Nurminen from Aalto University.

Reuben Bond
  • 2,131
  • 15
  • 20
Enrichman
  • 11,157
  • 11
  • 67
  • 101
  • The fact that authors haven't provided any version info neither for java or scala makes this research highly suspicious. – om-nom-nom Sep 30 '13 at 13:41
  • Also to me seemed too much "vague" but it was the only thing I've found around. – Enrichman Sep 30 '13 at 13:44
  • The conclusion is fairly strong considering the benchmarks seemed to slightly favour Scala for performance and the energy consumption delta was not very large. Scala energy consumption varied from ~10% greater to ~30% greater on average for the two tests. The results are vague. – Reuben Bond Dec 26 '13 at 12:35
5

While Scala "will just work", because it is compiled to byte code just like Java, there are performance issues to consider. Idiomatic Scala code tends to create a lot more temporary objects, and the Dalvik VM doesn't take too kindly to these.

Here are some things you should be careful with when using Scala on Android:

  • Vectors, as they can be wasteful (always take up arrays of 32 items, even if you hold just one item)
  • Method chaining on collections - you should use .view wherever possible, to avoid creating redundant collections.
  • Boxing - Scala will box your primitives in various cases, like using Generics, using Option[Int], and in some anonymous functions.
  • for loops can waste memory, consider replacing them with while loops in sensitive sections
  • Implicit conversions - calls like str.indexWhere(...)will allocate a wrapper object on the string. Can be wasteful.
  • Scala's Map will allocate an Option[V] every time you access a key. I've had to replace it with Java's HashMap on occasion.

Of course, you should only optimize the places that are bottlenecks after using a profiler.

You can read more about the suggestions above in this blog post: http://blogs.microsoft.co.il/dorony/2014/10/07/scala-performance-tips-on-android/

Doron Yaacoby
  • 9,412
  • 8
  • 48
  • 59
2

Scala compiler will create JVM byte code. So basically at the lower level, it's just like running Java. So the performance will be equivalent to Java.

However, how the Scala compiler creates the byte code may have some impact on performance. I'd say since Scala is new and due to possible inefficiency in its byte code generation, Scala would be a bit slower than Java on Android, though not by a lot.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Aneesh
  • 1,703
  • 3
  • 24
  • 34
  • I gave the facts. Measuring performance itself is indeed a guess in this case. Theoretically, java and scala have the same bytecode so they can reach the same performance. But as for the actual performance,that depends on the programmer. A good scala program will be faster than a bad java one. Also same programming approach don't apply to java and scala as @om-nom-nom said,who by the way gave a great explaination. – Aneesh Sep 30 '13 at 13:31
  • So, there's no way to answer the question in the general case. Scala isn't new, either, it's been out for nearly a decade. Its bytecode generation at a low level isn't the issue, either. – Dave Newton Sep 30 '13 at 13:38