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

// This is Scala
class Counter {
  private var x = 0
  def getCount() = {
    val y = x
    x += 1
    y
  }
}

// This is Java
class Counter {
  private int x = 0;

  private int x() {
    return x;
  }

  private void x_$eq(int x) {
    this.x = x;
  }

  public int getCounter() {
    int y = x();
    x_$eq(x() + 1);
    return y;
  }
}

Особого внимания заслуживает тот факт, что Scala всегда обращается к полям через геттеры и сеттеры, даже в других методах того же класса. Дело, однако, в том, что здесь не происходит никакого обертывания классов. То же самое, скомпилировано ли оно на Java или Scala.

Теперь Scala упрощает написание более медленного кода. Вот некоторые примеры:

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

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

• Также легко параметризовать функции, чтобы можно было передавать Int , что может привести к снижению производительности при работе с примитивами (в Scala, подклассы AnyVal ).

Вот пример класса, написанного на Scala двумя разными способами, где более компактный примерно в два раза медленнее:

class Hamming extends Iterator[BigInt] {
  import scala.collection.mutable.Queue
  val qs = Seq.fill(3)(new Queue[BigInt])
  def enqueue(n: BigInt) = qs zip Seq(2, 3, 5) foreach { case (q, m) => q enqueue n * m }
  def next = {
    val n = qs map (_.head) min;
    qs foreach { q => if (q.head == n) q.dequeue }
    enqueue(n)
    n
  }
  def hasNext = true
  qs foreach (_ enqueue 1)
}

class Hamming extends Iterator[BigInt] {
  import scala.collection.mutable.Queue
  val q2 = new Queue[BigInt]
  val q3 = new Queue[BigInt]
  val q5 = new Queue[BigInt]
  def enqueue(n: BigInt) = {
    q2 enqueue n * 2
    q3 enqueue n * 3
    q5 enqueue n * 5
  }
  def next = {
    val n = q2.head min q3.head min q5.head
    if (q2.head == n) q2.dequeue
    if (q3.head == n) q3.dequeue
    if (q5.head == n) q5.dequeue
    enqueue(n)
    n
  }
  def hasNext = true
  List(q2, q3, q5) foreach (_ enqueue 1)
}

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

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

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

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

ретроним, а у Дэвида есть рассмотрены основные моменты, касающиеся Scala: он по сути так же быстр, как Java, и это так, потому что он статически типизирован (таким образом, не требует дополнительных проверок во время выполнения) и использует легкие оболочки, которые JVM обычно может полностью удалить.

Scala действительно упрощает использование мощных универсальных библиотечных функций. Как и с любой мощной универсальной библиотекой в ​​Java, с ней связано некоторое снижение производительности. Например, использование java.util.HashMap для реализации сопоставления байтов и байтов будет мучительно медленным в Java (по сравнению с примитивной таблицей поиска в массиве), и в Scala оно будет столь же медленным. Но Scala предоставляет вам гораздо больше возможностей такого рода и делает их удивительно простым вызовом, до такой степени, что вы действительно можете попросить о невероятном объеме работы, выполняемой с помощью очень небольшого количества кода. Как всегда, когда вы упрощаете задачу, чтобы просить о многом, люди иногда просят о многом, а затем задаются вопросом, почему это занимает так много времени. (И легкость вопроса делает это тем более удивительным, когда человек узнает (или тщательно обдумывает), что должно происходить за кулисами.)

Единственная законная критика, которую можно вызвать, это то, что Scala не делает это так просто, как она возможно мог написать высокопроизводительный код; большинство функций, упрощающих использование, направлены на универсальное функциональное программирование, которое по-прежнему выполняется довольно быстро, но не так быстро, как прямой доступ к примитивным типам.Например, в Scala есть невероятно мощный цикл for , но он использует универсальные типы, поэтому примитивы должны быть упакованы, и, следовательно, вы не можете эффективно использовать его для итерации по примитивным массивам; вместо этого вы должны использовать цикл while . (Разница в производительности, вероятно, уменьшится в версии 2.8 при использовании упомянутых ретронимов специализаций.)

Одна вещь, о которой следует знать: Java 7 представит новый invokedynamic байткод для JVM, который сделает ненужной большую часть "магии метаклассов" Groovy и должен значительно ускорить реализацию динамических языков на JVM.

Другие ответы посвящены специфике scala. Я хотел бы добавить несколько моментов для общего случая. Во-первых, вполне реально написать генератор байт-кода, который генерирует javac-подобный код, но на языке, отличном от java. Это становится сложнее, поскольку семантика языка отличается от семантики Java. Однако явная типизация не является частью семантики, только синтаксиса (и имеет свойства обнаружения ошибок).

Производительность снижается в том случае, если типы не могут быть определены статически (во время компиляции), или если язык является динамическим по своей природе (типизация динамическая, как во многих языках сценариев, таких как javascript, jython, jruby и т. Д.). В тех случаях с 1.6 jdk вам нужно выполнить диспетчеризацию на основе отражения. Это, очевидно, медленнее и не может быть легко оптимизировано с помощью точки доступа / виртуальной машины. Jdk 1.7 расширяет invokedynamic, чтобы его можно было использовать для динамического вызова функции, поддерживаемой языками сценариев.

Компилятор javac не выполняет столько оптимизаций (jvm выполняет их во время выполнения), поэтому язык java довольно просто отображает байт-код java. Это означает, что языки с одинаковой семантикой имеют преимущество по сравнению с языками с другой семантикой. Это недостаток JVM и место, где CLR (среда выполнения .net) и LLVM имеют явные преимущества.