Outros responderam a essa pergunta com relação a loops apertados, embora pareça haver uma óbvia diferença de desempenho entre os exemplos de Rex Kerr que eu comentei.
Essa resposta é realmente direcionada a pessoas que possam investigar a necessidade de otimização de loop apertado como falha de design.
Eu sou relativamente novo no Scala (cerca de um ano ou mais), mas a sensação até agora é que ele permite adiar muitos aspectos do design, implementação e execução com relativa facilidade (com leitura e experimentação suficientes em segundo plano :)
Recursos de design diferido:
Recursos de implementação adiada:
Recursos de execução adiada: (desculpe, sem links)
- Valores preguiçosos seguros para threads
- Pass-by-name
- Coisas monádicas
Esses recursos, para mim, são os que nos ajudam a trilhar o caminho para aplicativos rápidos e restritos.
Os exemplos de Rex Kerr diferem em quais aspectos da execução são adiados. No exemplo de Java, a alocação de memória é adiada até que seu tamanho seja calculado, onde o exemplo Scala adia a pesquisa de mapeamento. Para mim, eles parecem algoritmos completamente diferentes.
Aqui está o que eu acho que é mais equivalente a maçãs com maçãs para o seu exemplo de Java:
val bigEnough = array.collect({
case k: String if k.length > 2 && mapping.contains(k) => mapping(k)
})
Nenhuma coleção intermediários, há Optioncasos etc. Isto também preserva o tipo de coleção para bigEnough's tipo é Array[File]- Array' s collectimplementação provavelmente será fazer algo ao longo das linhas do que o código Java do Sr. Kerr faz.
Os recursos de design diferido listados acima também permitiriam que os desenvolvedores da API de coleção da Scala implementassem essa rápida implementação específica de coleta de Array em versões futuras sem interromper a API. É a isso que estou me referindo ao trilhar o caminho da velocidade.
Além disso:
val bigEnough = array.withFilter(_.length > 2).flatMap(mapping.get)
O withFiltermétodo que eu usei aqui em vez de filtercorrige o problema de coleção intermediária, mas ainda existe o problema da instância Option.
Um exemplo de velocidade de execução simples no Scala é com o log.
Em Java, podemos escrever algo como:
if (logger.isDebugEnabled())
logger.debug("trace");
Em Scala, isso é apenas:
logger.debug("trace")
porque o parâmetro de mensagem para depuração no Scala tem o tipo " => String" que eu considero uma função sem parâmetro que é executada quando é avaliada, mas que a documentação chama de pass-by-name.
EDIT {Funções no Scala são objetos, então há um objeto extra aqui. Para o meu trabalho, vale a pena o peso de um objeto trivial, removendo a possibilidade de uma mensagem de log ser avaliada desnecessariamente. }
Isso não torna o código mais rápido, mas aumenta a probabilidade de ser mais rápido e é menos provável que tenhamos a experiência de analisar e limpar o código de outras pessoas em massa.
Para mim, esse é um tema consistente no Scala.
O código rígido falha ao capturar o motivo pelo qual o Scala é mais rápido, apesar de sugerir um pouco.
Eu sinto que é uma combinação de reutilização de código e o limite máximo de qualidade de código no Scala.
Em Java, o código impressionante geralmente é forçado a se tornar uma bagunça incompreensível e, portanto, não é realmente viável nas APIs de qualidade de produção, pois a maioria dos programadores não seria capaz de usá-lo.
Tenho grandes esperanças de que o Scala permita que os einsteins entre nós implementem APIs muito mais competentes, potencialmente expressas por meio de DSLs. As principais APIs do Scala já estão distantes nesse caminho.