Производительность Scala для Android

Ответ 1

Объяснить немного @Aneesh answer - Да, нет дополнительной работы для интерпретации байт-кода Scala, потому что он точно такие же биты и куски, что и байт-код Java.

Обратите внимание, что также есть байт-код Java bytecode = > Dalvik при запуске кода на Android.

Но используя те же кирпичи, вы можете построить велосипед, а другой парень может построить городской городок. Например, из-за того, что язык поощряет неизменность Scala генерирует много коротких живых объектов. Для зрелых JVM, таких как HotSpot, это не имеет большого значения в течение примерно десятилетия. Но для Dalvik это проблема (до пула объектов недавних версий и жесткое повторное использование уже созданных объектов было одним из самых распространенных советы по производительности даже для Java).

Далее, запись val не совпадает с записью final Foo bar = .... Внутренне этот код представлен как поле + getter (если вы не префикс val с private [this], который будет переведен в обычное конечное поле). var преобразуется в поле + getter + setter. Почему это важно?

В старых версиях Android (до 2.2) вообще не было JIT, поэтому this оказывается около 3x-7x штрафа по сравнению с прямым доступом к полю. И, наконец, в то время как Google инструктирует вас избегать внутренних классов и предпочитает пакеты вместо, Scala создаст много внутренних классов, даже если вы Так пишите. Рассмотрим этот код:

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

Сколько внутренних классов будет создано? Вы можете сказать, что нет, но если вы запустите scalac, вы увидите:

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

Таким образом, будет наказание, особенно если вы напишете идиоматический код Scala с большим количеством неизменяемости и синтаксиса сахара. Дело в том, что это сильно зависит от вашего развертывания (вы нацеливаете новые устройства?) И фактических шаблонов кода (вы всегда можете вернуться к Java или хотя бы записать меньше идиоматического кода в критических точках производительности), и некоторые из упомянутых там проблем будут (последний) в следующих версиях.

Исходное изображение источник был Wikipedia.

См. также вопрос о переполнении стека Использует ли Scala на Android стоит? Много накладных расходов? Проблемы? для возможных проблем, с которыми вы можете столкнуться во время разработки.

Ответ 2

Я нашел эту статью, показывающую некоторые ориентиры между двумя языками:

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

Я не читал всю статью, но, в конце концов, кажется, что они дадут точку в Java:

В заключение мы считаем, что Scala не будет играть главную роль в развития мобильных приложений в будущем, из-за важности сохраняя низкое потребление энергии на устройстве. Сильная сторона язык Scala - это то, как его компоненты масштабируются, а не большое значение в мобильных устройствах, где приложения, как правило, не масштаб вообще и оставаться небольшим.

Кредиты Маттиа Денти и Юкки К. Нурминен из Университета Аалто.

Ответ 3

Пока Scala "будет работать", потому что он скомпилирован в байтовый код, как Java, есть проблемы с производительностью. Идиоматический код Scala имеет тенденцию создавать намного более временные объекты, а Dalvik VM не слишком любезно относится к ним.

Вот некоторые вещи, о которых вы должны быть осторожны при использовании Scala на Android:

• Векторы, поскольку они могут быть расточительными (всегда занимают массивы из 32 элементов, даже если вы держите только один элемент).
• Цепочка методов для коллекций - вы должны использовать .view везде, где это возможно, чтобы избежать создания избыточных коллекций.
• Бокс - Scala будет вставлять ваши примитивы в разных случаях, например, с помощью Generics, используя Option [Int] и в некоторых анонимных функциях.
• для циклов может потерять память, подумайте о замене их на циклы while в чувствительных разделах
• Неявные преобразования - вызовы типа str.indexWhere(...) будут выделять объект-оболочку в строке. Может быть расточительным.
• Scala Карта будет выделять опцию [V] каждый раз, когда вы получаете доступ к ключу. Мне пришлось иногда заменять его Java HashMap.

Конечно, вы должны оптимизировать места, которые являются узкими местами после использования профилировщика.

Вы можете больше узнать о предложениях, приведенных выше в этом сообщении в блоге: http://blogs.microsoft.co.il/dorony/2014/10/07/scala-performance-tips-on-android/

Ответ 4

Scala компилятор создаст байт-код JVM. Таким образом, в основном на более низком уровне это просто работает с Java. Таким образом, производительность будет эквивалентна Java.

Однако, как компилятор Scala создает байтовый код может иметь некоторое влияние на производительность. Я бы сказал, с тех пор, как Scala является новым и из-за возможной неэффективности генерации его байтового кода, Scala будет немного медленнее, чем Java на Android, хотя и не много.