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

Я только начал изучать Скала , и у меня есть время в моей жизни. Сегодня я также только что услышал о Scala для Android, и я полностью подключен.

Однако, учитывая, что Scala похожа на супермножество Java в том, что это Java ++ (я имею в виду Java с большим количеством включенных данных), мне интересно, как именно Scala-код будет работать в Android?

Кроме того, повлияет ли производительность приложения для Android, если она будет написана с помощью Scala? То есть, если есть какая-то дополнительная работа, необходимая для интерпретации кода Scala.

Solutions Collecting From Web of "Производительность Scala для Android"

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

Введите описание изображения здесь

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

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

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

В старых версиях Android (до 2.2) вообще не было JIT , так что это примерно равно 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 или хотя бы записать меньше идиоматического кода в критических точках производительности), и некоторые из упомянутых там проблем будут (Последний) в следующих версиях.

Исходным источником изображения была Википедия .

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

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

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

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

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

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

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

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

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

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

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

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

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