scala vs java, производительность и память?

Я новый пользователь, поэтому я не могу добавить комментарий к ответу Rex Kerr выше (позволяя новым пользователям "отвечать", но не "комментарий" - очень странное правило btw).

Я подписался просто, чтобы ответить на "phew, Java настолько многословный и такой тяжелый труд", в котором упоминается популярный ответ Rex выше. Хотя вы можете, конечно, написать более сжатый код Scala, приведенный пример Java явно раздувается. Большинство разработчиков Java кодируют что-то вроде этого:

List<String> bigEnough = new ArrayList<String>();
for(String s : array) {
  if(s.length() > 2 && mapping.get(s) != null) {
    bigEnough.add(mapping.get(s));
  }
}

И, конечно, если мы собираемся притвориться, что Eclipse не делает большую часть фактического ввода для вас и что каждый сохраненный символ действительно делает вас лучшим программистом, тогда вы можете это сделать:

List b=new ArrayList();
for(String s:array)
  if(s.length()>2 && mapping.get(s) != null) b.add(mapping.get(s));

Теперь я не только сохранил время, когда потребовалось ввести полные имена переменных и фигурные скобки (освободить меня, чтобы потратить еще 5 секунд, чтобы задуматься о глубоких алгоритмических мыслях), но я также могу ввести свой код в конкурсы обфускации и потенциально заработать дополнительные деньги для праздников.

Запишите свой Scala как Java, и вы можете ожидать, что вы получите почти одинаковый байт-код - с почти одинаковыми метриками.

Запишите его более "идиоматично", с неизменяемыми объектами и функциями более высокого порядка, и это будет немного медленнее и немного больше. Единственным исключением из этого правила является использование общих объектов, в которых параметры типа используют аннотацию @specialised, это создаст еще больший байт-код, который может опередить производительность Java, избегая бокса/распаковки.

Также стоит упомянуть тот факт, что больше памяти/меньше скорости является неизбежным компромиссом при написании кода, который можно запускать параллельно. Идиоматический код Scala является гораздо более декларативным по своей природе, чем обычный Java-код, и часто является всего лишь 4 символами (.par) от полностью параллельного.

Итак, если

• Scala код занимает 1.25x длиннее кода Java в одном потоке
• Его можно легко разделить на 4 ядра (теперь они распространены даже в ноутбуках).
• для параллельного времени выполнения (1.24/4 =) 0.3125x оригинальной Java

Не могли бы вы сказать, что код Scala теперь сравнительно на 25% медленнее или в 3 раза быстрее?

Правильный ответ зависит от того, как вы определяете "производительность":)

Компьютерные игры Benchmarks Game:

Тест скорости java/ scala 1.71/2.25

Тест памяти java/ scala 66.55/80.81

Итак, в этих тестах говорится, что java на 24% быстрее, а scala использует на 21% больше памяти.

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

Нижняя строка: Если scala делает вас и вашу команду (и людей, которые проецируют проект, когда вы уходите), более продуктивны, тогда вы должны пойти на это.

Другие ответили на этот вопрос относительно жестких циклов, хотя, по-видимому, существует очевидная разница в производительности между примерами Рекса Керра, о которых я прокомментировал.

Этот ответ действительно нацелен на людей, которые могут исследовать потребность в оптимизации с использованием тесных циклов в качестве недостатка дизайна.

Я относительно не знаком с Scala (примерно год или около того), но до сих пор его ощущается, что он позволяет отложить многие аспекты проектирования, реализации и выполнения относительно легко (с достаточным количеством фоновых чтений и экспериментирование:)

Функции отложенного дизайна:

• Абстрактные типы
• Явно типизированные саморекламы
• Представления
• Mixins

Возможности отложенной реализации:

• Отклонения аннотации
• Составные типы
• Локальный запрос типа

Отложенные функции выполнения: (извините, никаких ссылок)

• Потоковые безопасные ленивые значения
• Pass-по имени
• Монадический материал

Эти функции для меня - это те, которые помогают нам прокладывать путь к быстрым, жестким приложениям.

---

Примеры Рекса Керра отличаются тем, какие аспекты исполнения отложены. В примере Java распределение памяти отложено до тех пор, пока не будет рассчитан размер, где пример Scala отменяет поиск по карте. Для меня они кажутся совершенно разными алгоритмами.

Здесь я думаю, что это больше яблок для яблок, эквивалентных его примеру Java:

val bigEnough = array.collect({
    case k: String if k.length > 2 && mapping.contains(k) => mapping(k)
})

Нет промежуточных коллекций, экземпляров Option и т.д. Это также сохраняет тип коллекции, поэтому bigEnough type is Array[File] - Array collect реализация, вероятно, будет делать что-то в соответствии с тем, что делает код Mr Kerr Java.

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

также:

val bigEnough = array.withFilter(_.length > 2).flatMap(mapping.get)

Метод withFilter, который я использовал здесь вместо filter, исправляет проблему промежуточной коллекции, но проблема с экземпляром Option все еще сохраняется.

---

Один пример простой скорости выполнения в Scala - с протоколированием.

В Java мы можем написать что-то вроде:

if (logger.isDebugEnabled())
    logger.debug("trace");

В Scala это справедливо:

logger.debug("trace")

потому что параметр сообщения для отладки в Scala имеет тип "=> String", который я считаю как функция без параметра, выполняемая при ее оценке, но которую документация вызывает pass-by-name.

EDIT { Функции в Scala являются объектами, поэтому здесь есть дополнительный объект. Для моей работы вес тривиального объекта стоит удалить возможность того, что сообщение журнала становится бесполезно оценено. }

Это не ускоряет работу кода, но делает его более быстрым, и мы с меньшей вероятностью будем иметь опыт прохождения и очистки кода других людей.

Для меня это согласованная тема в Scala.

---

Жесткий код не может понять, почему Scala работает быстрее, хотя он немного намекает.

Я чувствую, что это сочетание повторного использования кода и потолка качества кода в Scala.

В Java удивительный код часто вынужден стать непостижимым беспорядком, и поэтому он не очень жизнеспособен в API качества продукции, поскольку большинство программистов его не смогут использовать.

У меня есть большие надежды, что Scala может позволить эйнштейнам среди нас внедрять гораздо более компетентные API, потенциально выраженные через DSL. Основные API в Scala уже далеко по этому пути.

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

Действительно, они оба настолько близки, что не стоит беспокоиться. Повышение производительности, получаемое с помощью более выразительного языка, такого как Scala, стоит гораздо больше, чем минимальная (если таковая имеется) производительность.

презентация @более высокого уровня по теме - Scala Рекомендации по производительности, которые выполняют некоторые сравнения Java/ Scala.

Инструменты:

• ScalaMeter
• scala-benchmarking-template

Отличная blogpost:

• Нанотравить Nanotime

Пример Java действительно не является идиомой для типичных прикладных программ. Такой оптимизированный код может быть найден в методе системной библиотеки. Но тогда он будет использовать массив правильного типа, т.е. File [], и не будет генерировать исключение IndexOutOfBoundsException. (Различные условия фильтрации для подсчета и добавления). Моя версия будет (всегда (!) С фигурными фигурными скобками, потому что я не люблю тратить час на поиск ошибки, которая была введена путем сохранения 2 секунд, чтобы нажать один ключ в Eclipse):

List<File> bigEnough = new ArrayList<File>();
for(String s : array) {
  if(s.length() > 2) {
    File file = mapping.get(s);
    if (file != null) {
      bigEnough.add(file);
    }
  }
}

Но я мог бы принести вам много других уродливых примеров кода Java из моего текущего проекта. Я старался избегать типичного стиля копирования и модифицировать код кодирования, разлагая общие структуры и поведение.

В моем абстрактном базовом классе DAO у меня есть абстрактный внутренний класс для общего механизма кэширования. Для каждого конкретного типа объекта модели существует подкласс абстрактного базового класса DAO, в котором внутренний класс подклассифицирован для обеспечения реализации метода, который создает бизнес-объект при его загрузке из базы данных. (Мы не можем использовать инструмент ORM, потому что мы обращаемся к другой системе через собственный API.)

Этот код подклассов и экземпляров не совсем ясен в Java и будет очень читабельным в Scala.